Inferring radio type from clustering algorithms

ABSTRACT

Described embodiments provide systems and methods for inferring a network type and network conditions. The system includes a packet capturing engine configured to capture a plurality of network packets from a plurality of TCP network connections. The system includes a packet analyzer configured to analyze the plurality of network packets to generate a plurality of metrics. The system includes a network classifier configured to infer network types of the plurality of TCP connections based on the plurality of metrics and at least one classification model. The system also includes a conditions ranking engine configured to estimate a level of network congestion for each TCP connection based on the plurality of metrics and the network types.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of, and claims priority to andthe benefit of U.S. application Ser. No. 15/938,769, filed on Mar. 28,2018, and titled “INFERRING RADIO TYPE FROM CLUSTERING ALGORITHMS”,which claims priority to and the benefit of U.S. Provisional ApplicationNo. 62/552,207, filed on Aug. 30, 2017, and titled “ADVANCED NETWORKANALYTICS”, the entire contents of both of which are herein incorporatedby reference.

BACKGROUND

A computing environment can be configured to facilitate connectionsbetween user equipment, such as mobile phones, and other computingdevices. For example, cellular networks allow users to communicate viamobile phones using a variety of network protocols and technologies.Network performance in a cellular network can be influenced by factorsincluding signal strength and network congestion. However, it can bedifficult to gain insight into the specific underlying causes of poornetwork performance by analyzing packets sent over the network.

SUMMARY

The present disclosure is directed towards systems and methods forclassifying TCP connections in terms of network type and estimatingnetwork conditions. The present solution examines network packetstransmitted over TCP connections to generate various metrics relating tonetwork performance. Based on these metrics, the network type of the TCPconnection is inferred and then the signal quality and congestion levelof the network can be determined in near-real time.

The network type and network conditions experienced by mobile users canbe accurately inferred by inspecting the TCP packets anywhere in betweenthe connection's endpoints. Particularly, in mobile wireless networks,the radio access technology (e.g. 2G, 3G & 4G) can be inferred and theperceived network congestion (e.g. None, Medium, High) and signalquality (e.g. Excellent, Good, Poor) can be estimated. This disclosureincludes a novel design of a machine learning pipeline for inferring theradio access type of TCP connections with high accuracy. This disclosurealso includes elegant modeling of congestion and signal quality inmobile wireless networks, as well as non-intrusive monitoring of TCPconnections for producing advanced network analytics.

In the realm of mobile wireless networks, the degraded performance ofTCP is a well-known problem, as are its causes. However, the complexityand dynamics of TCP, in conjunction with the various radio linktechnologies used in mobile wireless networks, hinder the establishmentof a solid model that accounts for the perceived performance of a TCPconnection. This disclosure models the complex interactions of TCP withthe underlying radio access technologies and provides a comprehensiveinsight of the network in terms of performance and radio access types.As a result, the solutions provided in this disclosure allow the overallbehavior of the network to be analyzed, in terms of the conditionsexperienced by mobile subscribers. In the context of this use case,entities (e.g., cellular network service providers, content providerswho distribute content via a cellular network, etc.) can leverage thisfeature for network analysis, using the analytics for forward planning.Entities also can use the solutions provided in this disclosure formarket analysis by tracking success in user adoption or churn for userswith different devices and network types. In addition, this disclosureprovides solutions that can adapt a TCP profile, independently for eachsubscriber and in near-real time, based on their current networkconditions. In the context of this use case, an entity can use thisfeature to improve user experience by detecting wireless network typeand radio characteristics for configuring the optimal TCP profile peruser device. An entity also can use this feature for policy drivenactions, which can allow service and content providers to make decisionsbased on user experience (e.g., smaller files for more constrainedusers).

Adaptive TCP as described in this disclosure is likely to becomeincreasingly important in the future, mainly because of the increase ofthe average TCP connection size (in terms of bytes or duration) and theadoption of new network technologies. Given that, congestion controlalgorithms should maintain their efficiency for even more networktechnologies. Providing comprehensive network analytics in a centralizedand non-intrusive fashion renders the solutions of this disclosure moreappealing compared to distributed, probe-based solutions, which aretraditionally more expensive and harder to administrate.

An aspect provides a method for identifying a type of network of atransport layer connection. The method can include establishing metricsof network traffic traversing one or more devices via a plurality oftransport layer connections providing communications with a plurality oftypes of networks. The metrics can include at least inter-arrivalintervals of packets of the network traffic. The method can includeclassifying, by a network classifier, the plurality of types of networksinto a classification model using at least the metrics of the pluralityof types of networks. The method can include identifying, by the networkclassifier responsive to a device receiving one or more packets for atransport layer connection, a type of network of the plurality of typesof networks for the transport layer connection based at least on metricsof the one or more packets and the classification model.

In some embodiments, the method can include capturing packets from thenetwork traffic of the plurality of transport layer connectionstraversing the one or more devices. In some embodiments, the pluralityof types of networks can include one of a mobile network or a fixednetwork. In some embodiments, the mobile network can include one of a2G, 3G, 4G or 5G network.

In some embodiments, the metrics can include one or more of thefollowing: average throughput, average instantaneous throughput, averageinter-arrival intervals, average inter-sending interval, maximum roundtrip time, minimum round trip time, average round trip time, averageload delay and average noise delay. In some embodiments, the metrics caninclude one or more of the following: a percentage of packets of thenetwork traffic within a predetermined inter-arrival interval and aprobability of a packet having the inter-arrival interval within thepredetermined inter-arrival interval.

In some embodiments, the transport layer connection can be establishedwith a mobile device via the type of network comprising a mobilenetwork. In some embodiments, the method can include inferring, by thenetwork classifier, the type of network for the transport layerconnection based at least on comparing the metrics of the one or morepackets to the classification model established by the networkclassifier for the plurality of types of networks. In some embodiments,the method can include distinguishing, by the network classifier,between different types of networks based on the inter-arrival intervalsof the metrics. In some embodiments, the method can includedistinguishing, by the network classifier, between different types ofnetworks based on the average minimum round trip times of the metrics.

Another aspect provides a system for identifying a type of network of atransport layer connection. The system can include a network classifierexecutable on one or more processors, coupled to memory, and configuredto receive metrics of network traffic traversing the one or more devicesvia a plurality of transport layer connections providing communicationswith a plurality of types of networks. The metrics can include at leastinter-arrival intervals of packets of the network traffic. The networkclassifier can be configured to classify the plurality of types ofnetworks into a classification model using at least the metric of theplurality of types of networks. The network classifier can be configuredto identify, responsive to a device receiving one or more packets beingfor a transport layer connection, a type of network of the plurality oftypes of networks for the transport layer connection based at least onmetrics of the one or more packets and the classification model.

In some embodiments, packets are captured from the network traffic ofthe plurality of transport layer connections traversing the one or moredevices. In some embodiments, the plurality of types of networks caninclude one of a mobile network or a fixed network. In some embodiments,the mobile network can include one of a 2G, 3G, 4G or 5G network.

In some embodiments, the metrics can include one or more of thefollowing: average throughput, average instantaneous throughput, averageinter-arrival intervals, average inter-sending interval, maximum roundtrip time, minimum round trip time, average round trip time, averageload delay and average noise delay. In some embodiments, the metrics caninclude one or more of the following: a percentage of packets of thenetwork traffic within a predetermined inter-arrival interval and aprobability of a packet having the inter-arrival interval within thepredetermined inter-arrival interval.

In some embodiments, the transport layer connection can be establishedwith a mobile device via the type of network including a mobile network.In some embodiments, the network classifier can be further configured toinfer the type of network for the transport layer connection based atleast on comparing the metrics of the one or more packets to theclassification model established by the network classifier for theplurality of types of networks. In some embodiments, the networkclassifier can be further configured to distinguish between differenttypes of networks based on the inter-arrival intervals of the metrics.In some embodiments, the network classifier can be further configured todistinguish between different types of networks based on the averageminimum round trip times of the metrics.

Another aspect provides a method for determining network congestion andsignal quality for a transport layer connection. The method can includeestablishing, by a network classifier executing on one or moreprocessors, a classification model for a plurality of types of networksbased on metrics of network traffic traversing one or more devices for aplurality of transport layer connections providing communications with aplurality of types of networks. The method can include receiving, by thenetwork classifier, metrics of a plurality of packets for a transportlayer connection. The method can include classifying, by the networkclassifier, a type of network for the transport layer connection basedat least on the metrics and the classification model. The method caninclude determining, by the one or more processors, a level ofcongestion and a signal quality for the transport layer connection basedon the metrics and the classification of the type of network. The methodcan include providing, by the one or more processors for display via auser interface, the level of congestion and the signal quality for thetransport layer connection.

In some embodiments, the plurality of types of networks can include oneof a type of a mobile network or a type of a fixed network. In someembodiments, the type of the mobile network can include one of a 2G, 3G,4G or 5G network.

In some embodiments, the method can include determining from the metricsa load and noise delay per packet of the plurality of packets. In someembodiments, the method can include determining an average load delayand average noise delay for the transport layer connection. In someembodiments, the method can include determining a relative average loaddelay and relative average noise delay with respect to an averageconnection delay for the transport layer connection.

In some embodiments, the method can include determining an idealthroughput metric based at least on a number of bytes transferred andexcluding network congestion and noise. In some embodiments, the methodcan include determining a degradation percentage for the transport layerconnection based on a function of the ideal throughput metric and anaverage throughput of the transport layer connection. In someembodiments, the method can include determining the level of congestionfor the transport layer connection based on a function of the idealthroughput metric and the load delay. In some embodiments, the methodcan include determining the signal quality for the transport layerconnection based on a function of the ideal throughput metric and thenoise delay.

Another aspect provides a system for identifying network congestion andsignal quality for a transport layer connection. The system can includea network classifier executable on one or more processors, coupled tomemory and configured to establish a classification model for aplurality of types of networks based on metrics of network traffictraversing one or more devices for a plurality of transport layerconnections providing communications with a plurality of types ofnetworks. The network classifier can be configured to receive metrics ofa plurality of packets for a transport layer connection. The networkclassifier can be configured to classify a type of network for thetransport layer connection based at least on the metrics and theclassification model. The one or more processors can be configured todetermine a level of congestion and a signal quality for the transportlayer connection based on the metrics and the classification of the typeof network and provide for display via a user interface the level ofcongestion and the signal quality for the transport layer connection.

In some embodiments, the plurality of types of networks can include oneof a type of a mobile network or a type of a fixed network. In someembodiments, the type of the mobile network can include one of a 2G, 3G,4G or 5G network.

In some embodiments, the one or more processors can be furtherconfigured to determine from the metrics a load and noise delay perpacket of the plurality of packets. In some embodiments, the one or moreprocessors can be further configured to determine an average load delayand average noise delay for the transport layer connection. In someembodiments, the one or more processors can be further configured todetermine a relative average load delay and relative average noise delaywith respect to an average connection delay for the transport layerconnection.

In some embodiments, the one or more processors can be furtherconfigured to determine an ideal throughput metric based at least on anumber of bytes transferred and excluding network congestion and noise.In some embodiments, the one or more processors can be furtherconfigured to determine a degradation percentage for the transport layerconnection based on a function of the ideal throughput metric and anaverage throughput of the transport layer connection. In someembodiments, the one or more processors can be further configured todetermine the level of congestion for the transport layer connectionbased on a function of the ideal throughput metric and the load delay.In some embodiments, the one or more processors can be furtherconfigured to determine the signal quality for the transport layerconnection based on a function of the ideal throughput metric and thenoise delay.

Another aspect provides a method for generating classification modelsbased on advanced network analytics to classify transport layer networkconnections. The method includes capturing a plurality of networkpackets from a plurality of TCP network connections. The method includesanalyzing the plurality of network packets to generate a plurality ofmetrics. The method includes collecting and consolidating the generatedmetrics for all analyzed TCP network connections. The method includesclustering the generated metrics to assign labels to the plurality ofTCP connections. The method also includes generating classificationmodels for the TCP connections.

Another aspect provides a system for generating classification modelsbased on advanced network analytics to classify transport layer networkconnections. The system includes a packet capturing engine configured tocapture a plurality of network packets from a plurality of TCP networkconnections. The system includes a packet analyzer configured to analyzethe plurality of network packets to generate a plurality of metrics. Thesystem includes a data accumulator configured to collect and consolidatethe generated metrics for all analyzed TCP network connections. Thesystem includes a data labeler configured to cluster the generatedmetrics to assign labels to the plurality of TCP connections. The systemalso includes a model generator configured to generate classificationmodels for the TCP connections.

Another aspect provides a method for inferring a network type andnetwork conditions. The method includes capturing a plurality of networkpackets from a plurality of TCP network connections. The method includesanalyzing the plurality of network packets to generate a plurality ofmetrics. The method includes inferring network types of the plurality ofTCP connections based on the plurality of metrics and at least oneclassification model. The method also includes estimating a level ofnetwork congestion for each TCP connection based on the plurality ofmetrics and the network types.

Another aspect provides a system for inferring a network type andnetwork conditions. The system includes a packet capturing engineconfigured to capture a plurality of network packets from a plurality ofTCP network connections. The system includes a packet analyzerconfigured to analyze the plurality of network packets to generate aplurality of metrics. The system includes a network classifierconfigured to infer network types of the plurality of TCP connectionsbased on the plurality of metrics and at least one classification model.The system also includes a conditions ranking engine configured toestimate a level of network congestion for each TCP connection based onthe plurality of metrics and the network types.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features, nor is it intended to limit the scope of the claimsincluded herewith.

BRIEF DESCRIPTION OF THE FIGURES

Objects, aspects, features, and advantages of embodiments disclosedherein will become more fully apparent from the following detaileddescription, the appended claims, and the accompanying drawing figuresin which like reference numerals identify similar or identical elements.Reference numerals that are introduced in the specification inassociation with a drawing figure may be repeated in one or moresubsequent figures without additional description in the specificationin order to provide context for other features, and not every elementmay be labeled in every figure. The drawing figures are not necessarilyto scale, emphasis instead being placed upon illustrating embodiments,principles and concepts. The drawings are not intended to limit thescope of the claims included herewith.

FIG. 1A is a block diagram of a network computing system, in accordancewith an illustrative embodiment;

FIG. 1B is a block diagram of a network computing system for deliveringa computing environment from a server to a client via an appliance, inaccordance with an illustrative embodiment;

FIG. 1C is a block diagram of a computing device, in accordance with anillustrative embodiment;

FIG. 2 is a block diagram of an appliance for processing communicationsbetween a client and a server, in accordance with an illustrativeembodiment;

FIG. 3 is a block diagram of a virtualization environment, in accordancewith an illustrative embodiment;

FIG. 4 is a block diagram of a cluster system, in accordance with anillustrative embodiment;

FIG. 5 is a block diagram of an embodiment of a mobile wirelesscomputing environment;

FIG. 6 depicts a wireless protocol stack for LTE and WCDMA;

FIG. 7A depicts an example process that illustrates the HARQ mechanism;

FIG. 7B depicts a plot 730 showing the packet delays in a TCPconnection;

FIG. 7C depicts an example Proportional Fair Scheduler;

FIG. 7D depicts a plot showing the cumulative distribution function(CDF) of inter-arrival/sending intervals of packets for a LTEconnection;

FIG. 7E depicts a plot showing the cumulative distribution function(CDF) of inter-arrival/sending intervals of packets for a WCDMAconnection

FIG. 8A is a block diagram of the network analytics system shown in FIG.5;

FIG. 8B is a flowchart of an example method for generatingclassification models;

FIG. 8C depicts a chart showing clusters of TCP connections by networktype;

FIG. 8D depicts a chart showing how connections of different networktypes are separated and identified by a data labeler;

FIG. 8E is a flowchart of an example method for inferring a networktype, network conditions, and signal quality;

FIG. 8F is a flowchart of an example method for identifying a type ofnetwork of a transport layer connection;

FIG. 8G is a flowchart of an example method for determining networkcongestion and signal quality for a transport layer connection;

FIGS. 9A-9C illustrate algorithms that can be used to estimate load andnoise delays;

FIG. 10A depicts a plot showing fitted curve line over a number ofconnections;

FIG. 10B shows a plot depicting a model representing the way in whichcongestion and noise affects performance of TCP connections with varyinglengths;

FIGS. 11A-11D depict a sample collection of analytics reports;

FIGS. 12A and 12B depict a sample collection of evaluation reports;

FIG. 13 is an example high-level architecture block diagram;

FIG. 14 is an example mobile network for illustrating network congestionand signal quality;

FIG. 15 illustrates network layers in various mobile networktechnologies;

FIG. 16 illustrates retransmission interval thresholds for 3G and 4Gnetworks;

FIG. 17 is a plot showing delays caused by congestion and noise;

FIG. 18 is a plot showing classes resulting from a mapping of CQIefficiency index and CQR;

FIGS. 19A and 19B are graphs showing the discrimination levels formodels using different parameters;

FIGS. 20A and 20B show experimental results for various models that arepertinent to network conditions;

FIG. 21 shows a plot estimating the maximum theoretical throughput of aconnection for one example computing environment;

FIG. 22 shows a plot depicting a model representing the way in whichcongestion and noise affects performance of TCP connections with thesame connection lengths; and

FIGS. 23A and 23B show the results of implementing the above CCL/CSQalgorithms for 3G and 4G network types.

DETAILED DESCRIPTION

For purposes of reading the description of the various embodimentsbelow, the following descriptions of the sections of the specificationand their respective contents may be helpful:

Section A describes a computing environment which may be useful forpracticing embodiments described herein; and

Section B describes systems and methods for using advanced networkanalytics to classify transport layer connections.

A. Computing Environment

Prior to discussing the specifics of embodiments of the systems andmethods of an appliance and/or client, it may be helpful to discuss thecomputing environments in which such embodiments may be deployed.

Referring to FIG. 1A, an illustrative network environment 100 isdepicted. Network environment 100 may include one or more clients102(1)-102(n) (also generally referred to as local machine(s) 102 orclient(s) 102) in communication with one or more servers 106(1)-106(n)(also generally referred to as remote machine(s) 106 or server(s) 106)via one or more networks 104(1)-104 n (generally referred to asnetwork(s) 104). In some embodiments, a client 102 may communicate witha server 106 via one or more appliances 200(1)-200 n (generally referredto as appliance(s) 200 or gateway(s) 200).

Although the embodiment shown in FIG. 1A shows one or more networks 104between clients 102 and servers 106, in other embodiments, clients 102and servers 106 may be on the same network 104. The various networks 104may be the same type of network or different types of networks. Forexample, in some embodiments, network 104(1) may be a private networksuch as a local area network (LAN) or a company Intranet, while network104(2) and/or network 104(n) may be a public network, such as a widearea network (WAN) or the Internet. In other embodiments, both network104(1) and network 104(n) may be private networks. Networks 104 mayemploy one or more types of physical networks and/or network topologies,such as wired and/or wireless networks, and may employ one or morecommunication transport protocols, such as transmission control protocol(TCP), internet protocol (IP), user datagram protocol (UDP) or othersimilar protocols.

As shown in FIG. 1A, one or more appliances 200 may be located atvarious points or in various communication paths of network environment100. For example, appliance 200 may be deployed between two networks104(1) and 104(2), and appliances 200 may communicate with one anotherto work in conjunction to, for example, accelerate network trafficbetween clients 102 and servers 106. In other embodiments, the appliance200 may be located on a network 104. For example, appliance 200 may beimplemented as part of one of clients 102 and/or servers 106. In anembodiment, appliance 200 may be implemented as a network device such asNetScaler® products sold by Citrix Systems, Inc. of Fort Lauderdale,Fla.

As shown in FIG. 1A, one or more servers 106 may operate as a serverfarm 38. Servers 106 of server farm 38 may be logically grouped, and mayeither be geographically co-located (e.g., on premises) orgeographically dispersed (e.g., cloud based) from clients 102 and/orother servers 106. In an embodiment, server farm 38 executes one or moreapplications on behalf of one or more of clients 102 (e.g., as anapplication server), although other uses are possible, such as a fileserver, gateway server, proxy server, or other similar server uses.Clients 102 may seek access to hosted applications on servers 106.

As shown in FIG. 1A, in some embodiments, appliances 200 may include, bereplaced by, or be in communication with, one or more additionalappliances, such as WAN optimization appliances 205(1)-205(n), referredto generally as WAN optimization appliance(s) 205. For example, WANoptimization appliance 205 may accelerate, cache, compress or otherwiseoptimize or improve performance, operation, flow control, or quality ofservice of network traffic, such as traffic to and/or from a WANconnection, such as optimizing Wide Area File Services (WAFS),accelerating Server Message Block (SMB) or Common Internet File System(CIFS). In some embodiments, appliance 205 may be a performanceenhancing proxy or a WAN optimization controller. In one embodiment,appliance 205 may be implemented as CloudBridge® products sold by CitrixSystems, Inc. of Fort Lauderdale, Fla.

Referring to FIG. 1B, an example network environment, 100′, fordelivering and/or operating a computing network environment on a client102 is shown. As shown in FIG. 1B, a server 106 may include anapplication delivery system 190 for delivering a computing environment,application, and/or data files to one or more clients 102. Client 102may include client agent 120 and computing environment 15. Computingenvironment 15 may execute or operate an application, 16, that accesses,processes or uses a data file 17. Computing environment 15, application16 and/or data file 17 may be delivered via appliance 200 and/or theserver 106.

Appliance 200 may accelerate delivery of all or a portion of computingenvironment 15 to a client 102, for example by the application deliverysystem 190. For example, appliance 200 may accelerate delivery of astreaming application and data file processable by the application froma data center to a remote user location by accelerating transport layertraffic between a client 102 and a server 106. Such acceleration may beprovided by one or more techniques, such as: 1) transport layerconnection pooling, 2) transport layer connection multiplexing, 3)transport control protocol buffering, 4) compression, 5) caching, orother techniques. Appliance 200 may also provide load balancing ofservers 106 to process requests from clients 102, act as a proxy oraccess server to provide access to the one or more servers 106, providesecurity and/or act as a firewall between a client 102 and a server 106,provide Domain Name Service (DNS) resolution, provide one or morevirtual servers or virtual internet protocol servers, and/or provide asecure virtual private network (VPN) connection from a client 102 to aserver 106, such as a secure socket layer (SSL) VPN connection and/orprovide encryption and decryption operations.

Application delivery management system 190 may deliver computingenvironment 15 to a user (e.g., client 102), remote or otherwise, basedon authentication and authorization policies applied by policy engine195. A remote user may obtain a computing environment and access toserver stored applications and data files from any network-connecteddevice (e.g., client 102). For example, appliance 200 may request anapplication and data file from server 106. In response to the request,application delivery system 190 and/or server 106 may deliver theapplication and data file to client 102, for example via an applicationstream to operate in computing environment 15 on client 102, or via aremote-display protocol or otherwise via remote-based or server-basedcomputing. In an embodiment, application delivery system 190 may beimplemented as any portion of the Citrix Workspace Suite™ by CitrixSystems, Inc., such as XenApp® or XenDesktop®.

Policy engine 195 may control and manage the access to, and executionand delivery of, applications. For example, policy engine 195 maydetermine the one or more applications a user or client 102 may accessand/or how the application should be delivered to the user or client102, such as a server-based computing, streaming or delivering theapplication locally to the client 120 for local execution.

For example, in operation, a client 102 may request execution of anapplication (e.g., application 16′) and application delivery system 190of server 106 determines how to execute application 16′, for examplebased upon credentials received from client 102 and a user policyapplied by policy engine 195 associated with the credentials. Forexample, application delivery system 190 may enable client 102 toreceive application-output data generated by execution of theapplication on a server 106, may enable client 102 to execute theapplication locally after receiving the application from server 106, ormay stream the application via network 104 to client 102. For example,in some embodiments, the application may be a server-based or aremote-based application executed on server 106 on behalf of client 102.Server 106 may display output to client 102 using a thin-client orremote-display protocol, such as the Independent Computing Architecture(ICA) protocol by Citrix Systems, Inc. of Fort Lauderdale, Fla. Theapplication may be any application related to real-time datacommunications, such as applications for streaming graphics, streamingvideo and/or audio or other data, delivery of remote desktops orworkspaces or hosted services or applications, for exampleinfrastructure as a service (IaaS), workspace as a service (WaaS),software as a service (SaaS) or platform as a service (PaaS).

One or more of servers 106 may include a performance monitoring serviceor agent 197. In some embodiments, a dedicated one or more servers 106may be employed to perform performance monitoring. Performancemonitoring may be performed using data collection, aggregation,analysis, management and reporting, for example by software, hardware ora combination thereof. Performance monitoring may include one or moreagents for performing monitoring, measurement and data collectionactivities on clients 102 (e.g., client agent 120), servers 106 (e.g.,agent 197) or an appliances 200 and/or 205 (agent not shown). Ingeneral, monitoring agents (e.g., 120 and/or 197) execute transparently(e.g., in the background) to any application and/or user of the device.In some embodiments, monitoring agent 197 includes any of the productembodiments referred to as EdgeSight by Citrix Systems, Inc. of FortLauderdale, Fla.

The monitoring agents may monitor, measure, collect, and/or analyze dataon a predetermined frequency, based upon an occurrence of givenevent(s), or in real time during operation of network environment 100.The monitoring agents may monitor resource consumption and/orperformance of hardware, software, and/or communications resources ofclients 102, networks 104, appliances 200 and/or 205, and/or servers106. For example, network connections such as a transport layerconnection, network latency, bandwidth utilization, end-user responsetimes, application usage and performance, session connections to anapplication, cache usage, memory usage, processor usage, storage usage,database transactions, client and/or server utilization, active users,duration of user activity, application crashes, errors, or hangs, thetime required to log-in to an application, a server, or the applicationdelivery system, and/or other performance conditions and metrics may bemonitored.

The monitoring agents may provide application performance management forapplication delivery system 190. For example, based upon one or moremonitored performance conditions or metrics, application delivery system190 may be dynamically adjusted, for example periodically or inreal-time, to optimize application delivery by servers 106 to clients102 based upon network environment performance and conditions.

In described embodiments, clients 102, servers 106, and appliances 200and 205 may be deployed as and/or executed on any type and form ofcomputing device, such as any desktop computer, laptop computer, ormobile device capable of communication over at least one network andperforming the operations described herein. For example, clients 102,servers 106 and/or appliances 200 and 205 may each correspond to onecomputer, a plurality of computers, or a network of distributedcomputers such as computer 101 shown in FIG. 1C.

As shown in FIG. 1C, computer 101 may include one or more processors103, volatile memory 122 (e.g., RAM), non-volatile memory 128 (e.g., oneor more hard disk drives (HDDs) or other magnetic or optical storagemedia, one or more solid state drives (SSDs) such as a flash drive orother solid state storage media, one or more hybrid magnetic and solidstate drives, and/or one or more virtual storage volumes, such as acloud storage, or a combination of such physical storage volumes andvirtual storage volumes or arrays thereof), user interface (UI) 123, oneor more communications interfaces 118, and communication bus 150. Userinterface 123 may include graphical user interface (GUI) 124 (e.g., atouchscreen, a display, etc.) and one or more input/output (I/O) devices126 (e.g., a mouse, a keyboard, etc.). Non-volatile memory 128 storesoperating system 115, one or more applications 116, and data 117 suchthat, for example, computer instructions of operating system 115 and/orapplications 116 are executed by processor(s) 103 out of volatile memory122. Data may be entered using an input device of GUI 124 or receivedfrom I/O device(s) 126. Various elements of computer 101 may communicatevia communication bus 150. Computer 101 as shown in FIG. 1C is shownmerely as an example, as clients 102, servers 106 and/or appliances 200and 205 may be implemented by any computing or processing environmentand with any type of machine or set of machines that may have suitablehardware and/or software capable of operating as described herein.

Processor(s) 103 may be implemented by one or more programmableprocessors executing one or more computer programs to perform thefunctions of the system. As used herein, the term “processor” describesan electronic circuit that performs a function, an operation, or asequence of operations. The function, operation, or sequence ofoperations may be hard coded into the electronic circuit or soft codedby way of instructions held in a memory device. A “processor” mayperform the function, operation, or sequence of operations using digitalvalues or using analog signals. In some embodiments, the “processor” canbe embodied in one or more application specific integrated circuits(ASICs), microprocessors, digital signal processors, microcontrollers,field programmable gate arrays (FPGAs), programmable logic arrays(PLAs), multi-core processors, or general-purpose computers withassociated memory. The “processor” may be analog, digital ormixed-signal. In some embodiments, the “processor” may be one or morephysical processors or one or more “virtual” (e.g., remotely located or“cloud”) processors.

Communications interfaces 118 may include one or more interfaces toenable computer 101 to access a computer network such as a LAN, a WAN,or the Internet through a variety of wired and/or wireless or cellularconnections.

In described embodiments, a first computing device 101 may execute anapplication on behalf of a user of a client computing device (e.g., aclient 102), may execute a virtual machine, which provides an executionsession within which applications execute on behalf of a user or aclient computing device (e.g., a client 102), such as a hosted desktopsession, may execute a terminal services session to provide a hosteddesktop environment, or may provide access to a computing environmentincluding one or more of: one or more applications, one or more desktopapplications, and one or more desktop sessions in which one or moreapplications may execute.

Additional details of the embodiment and operation of networkenvironment 100, clients 102, servers 106, and appliances 200 and 205may be as described in U.S. Pat. No. 9,538,345, issued Jan. 3, 2017 toCitrix Systems, Inc. of Fort Lauderdale, Fla., the teachings of whichare hereby incorporated herein by reference.

FIG. 2 shows an example embodiment of appliance 200. As describedherein, appliance 200 may be implemented as a server, gateway, router,switch, bridge or other type of computing or network device. As shown inFIG. 2, an embodiment of appliance 200 may include a hardware layer 206and a software layer 205 divided into a user space 202 and a kernelspace 204. Hardware layer 206 provides the hardware elements upon whichprograms and services within kernel space 204 and user space 202 areexecuted and allow programs and services within kernel space 204 anduser space 202 to communicate data both internally and externally withrespect to appliance 200. As shown in FIG. 2, hardware layer 206 mayinclude one or more processing units 262 for executing software programsand services, memory 264 for storing software and data, network ports266 for transmitting and receiving data over a network, and encryptionprocessor 260 for encrypting and decrypting data such as in relation toSecure Socket Layer (SSL) or Transport Layer Security (TLS) processingof data transmitted and received over the network.

An operating system of appliance 200 allocates, manages, or otherwisesegregates the available system memory into kernel space 204 and userspace 202. Kernel space 204 is reserved for running kernel 230,including any device drivers, kernel extensions or other kernel relatedsoftware. As known to those skilled in the art, kernel 230 is the coreof the operating system, and provides access, control, and management ofresources and hardware-related elements of application 104. Kernel space204 may also include a number of network services or processes workingin conjunction with cache manager 232.

Appliance 200 may include one or more network stacks 267, such as aTCP/IP based stack, for communicating with client(s) 102, server(s) 106,network(s) 104, and/or other appliances 200 or 205. For example,appliance 200 may establish and/or terminate one or more transport layerconnections between clients 102 and servers 106. Each network stack 267may include a buffer 243 for queuing one or more network packets fortransmission by appliance 200.

Kernel space 204 may include cache manager 232, packet engine 240,encryption engine 234, policy engine 236 and compression engine 238. Inother words, one or more of processes 232, 240, 234, 236 and 238 run inthe core address space of the operating system of appliance 200, whichmay reduce the number of data transactions to and from the memory and/orcontext switches between kernel mode and user mode, for example sincedata obtained in kernel mode may not need to be passed or copied to auser process, thread or user level data structure.

Cache manager 232 may duplicate original data stored elsewhere or datapreviously computed, generated or transmitted to reducing the accesstime of the data. In some embodiments, the cache memory may be a dataobject in memory 264 of appliance 200, or may be a physical memoryhaving a faster access time than memory 264.

Policy engine 236 may include a statistical engine or otherconfiguration mechanism to allow a user to identify, specify, define orconfigure a caching policy and access, control and management ofobjects, data or content being cached by appliance 200, and define orconfigure security, network traffic, network access, compression orother functions performed by appliance 200.

Encryption engine 234 may process any security related protocol, such asSSL or TLS. For example, encryption engine 234 may encrypt and decryptnetwork packets, or any portion thereof, communicated via appliance 200,may setup or establish SSL, TLS or other secure connections, for examplebetween client 102, server 106, and/or other appliances 200 or 205. Insome embodiments, encryption engine 234 may use a tunneling protocol toprovide a VPN between a client 102 and a server 106. In someembodiments, encryption engine 234 is in communication with encryptionprocessor 260. Compression engine 238 compresses network packetsbi-directionally between clients 102 and servers 106 and/or between oneor more appliances 200.

Packet engine 240 may manage kernel-level processing of packets receivedand transmitted by appliance 200 via network stacks 267 to send andreceive network packets via network ports 266. Packet engine 240 mayoperate in conjunction with encryption engine 234, cache manager 232,policy engine 236 and compression engine 238, for example to performencryption/decryption, traffic management such as request-level contentswitching and request-level cache redirection, and compression anddecompression of data.

User space 202 is a memory area or portion of the operating system usedby user mode applications or programs otherwise running in user mode. Auser mode application may not access kernel space 204 directly and usesservice calls in order to access kernel services. User space 202 mayinclude graphical user interface (GUI) 210, a command line interface(CLI) 212, shell services 214, health monitor 216, and daemon services218. GUI 210 and CLI 212 enable a system administrator or other user tointeract with and control the operation of appliance 200, such as viathe operating system of appliance 200. Shell services 214 include theprograms, services, tasks, processes or executable instructions tosupport interaction with appliance 200 by a user via the GUI 210 and/orCLI 212.

Health monitor 216 monitors, checks, reports and ensures that networksystems are functioning properly and that users are receiving requestedcontent over a network, for example by monitoring activity of appliance200. In some embodiments, health monitor 216 intercepts and inspects anynetwork traffic passed via appliance 200. For example, health monitor216 may interface with one or more of encryption engine 234, cachemanager 232, policy engine 236, compression engine 238, packet engine240, daemon services 218, and shell services 214 to determine a state,status, operating condition, or health of any portion of the appliance200. Further, health monitor 216 may determine if a program, process,service or task is active and currently running, check status, error orhistory logs provided by any program, process, service or task todetermine any condition, status or error with any portion of appliance200. Additionally, health monitor 216 may measure and monitor theperformance of any application, program, process, service, task orthread executing on appliance 200.

Daemon services 218 are programs that run continuously or in thebackground and handle periodic service requests received by appliance200. In some embodiments, a daemon service may forward the requests toother programs or processes, such as another daemon service 218 asappropriate.

As described herein, appliance 200 may relieve servers 106 of much ofthe processing load caused by repeatedly opening and closing transportlayers connections to clients 102 by opening one or more transport layerconnections with each server 106 and maintaining these connections toallow repeated data accesses by clients via the Internet (e.g.,“connection pooling”). To perform connection pooling, appliance 200 maytranslate or multiplex communications by modifying sequence numbers andacknowledgment numbers at the transport layer protocol level (e.g.,“connection multiplexing”). Appliance 200 may also provide switching orload balancing for communications between the client 102 and server 106.

As described herein, each client 102 may include client agent 120 forestablishing and exchanging communications with appliance 200 and/orserver 106 via a network 104. Client 102 may have installed and/orexecute one or more applications that are in communication with network104. Client agent 120 may intercept network communications from anetwork stack used by the one or more applications. For example, clientagent 120 may intercept a network communication at any point in anetwork stack and redirect the network communication to a destinationdesired, managed or controlled by client agent 120, for example tointercept and redirect a transport layer connection to an IP address andport controlled or managed by client agent 120. Thus, client agent 120may transparently intercept any protocol layer below the transportlayer, such as the network layer, and any protocol layer above thetransport layer, such as the session, presentation or applicationlayers. Client agent 120 can interface with the transport layer tosecure, optimize, accelerate, route or load-balance any communicationsprovided via any protocol carried by the transport layer.

In some embodiments, client agent 120 is implemented as an IndependentComputing Architecture (ICA) client developed by Citrix Systems, Inc. ofFort Lauderdale, Fla. Client agent 120 may perform acceleration,streaming, monitoring, and/or other operations. For example, clientagent 120 may accelerate streaming an application from a server 106 to aclient 102. Client agent 120 may also perform end-pointdetection/scanning and collect end-point information about client 102for appliance 200 and/or server 106. Appliance 200 and/or server 106 mayuse the collected information to determine and provide access,authentication and authorization control of the client's connection tonetwork 104. For example, client agent 120 may identify and determineone or more client-side attributes, such as: the operating system and/ora version of an operating system, a service pack of the operatingsystem, a running service, a running process, a file, presence orversions of various applications of the client, such as antivirus,firewall, security, and/or other software.

Additional details of the embodiment and operation of appliance 200 maybe as described in U.S. Pat. No. 9,538,345, issued Jan. 3, 2017 toCitrix Systems, Inc. of Fort Lauderdale, Fla., the teachings of whichare hereby incorporated herein by reference.

Referring now to FIG. 3, a block diagram of a virtualized environment400 is shown. As shown, a computing device 402 in virtualizedenvironment 400 includes a virtualization layer 403, a hypervisor layer404, and a hardware layer 407. Hypervisor layer 404 includes one or morehypervisors (or virtualization managers) 401 that allocates and managesaccess to a number of physical resources in hardware layer 407 (e.g.,physical processor(s) 421 and physical disk(s) 428) by at least onevirtual machine (VM) (e.g., one of VMs 406) executing in virtualizationlayer 403. Each VM 406 may include allocated virtual resources such asvirtual processors 432 and/or virtual disks 442, as well as virtualresources such as virtual memory and virtual network interfaces. In someembodiments, at least one of VMs 406 may include a control operatingsystem (e.g., 405) in communication with hypervisor 401 and used toexecute applications for managing and configuring other VMs (e.g., guestoperating systems 410) on device 402.

In general, hypervisor(s) 401 may provide virtual resources to anoperating system of VMs 406 in any manner that simulates the operatingsystem having access to a physical device. Thus, hypervisor(s) 401 maybe used to emulate virtual hardware, partition physical hardware,virtualize physical hardware, and execute virtual machines that provideaccess to computing environments. In an illustrative embodiment,hypervisor(s) 401 may be implemented as a XEN hypervisor, for example asprovided by the open source Xen.org community. In an illustrativeembodiment, device 402 executing a hypervisor that creates a virtualmachine platform on which guest operating systems may execute isreferred to as a host server. In such an embodiment, device 402 may beimplemented as a XEN server as provided by Citrix Systems, Inc., of FortLauderdale, Fla.

Hypervisor 401 may create one or more VMs 406 in which an operatingsystem (e.g., control operating system 405 and/or guest operating system410) executes. For example, the hypervisor 401 loads a virtual machineimage to create VMs 406 to execute an operating system. Hypervisor 401may present VMs 406 with an abstraction of hardware layer 407, and/ormay control how physical capabilities of hardware layer 407 arepresented to VMs 406. For example, hypervisor(s) 401 may manage a poolof resources distributed across multiple physical computing devices.

In some embodiments, one of VMs 406 (e.g., the VM executing controloperating system 405) may manage and configure other of VMs 406, forexample by managing the execution and/or termination of a VM and/ormanaging allocation of virtual resources to a VM. In variousembodiments, VMs may communicate with hypervisor(s) 401 and/or other VMsvia, for example, one or more Application Programming Interfaces (APIs),shared memory, and/or other techniques.

In general, VMs 406 may provide a user of device 402 with access toresources within virtualized computing environment 400, for example, oneor more programs, applications, documents, files, desktop and/orcomputing environments, or other resources. In some embodiments, VMs 406may be implemented as fully virtualized VMs that are not aware that theyare virtual machines (e.g., a Hardware Virtual Machine or HVM). In otherembodiments, the VM may be aware that it is a virtual machine, and/orthe VM may be implemented as a paravirtualized (PV) VM.

Although shown in FIG. 3 as including a single virtualized device 402,virtualized environment 400 may include a plurality of networked devicesin a system in which at least one physical host executes a virtualmachine. A device on which a VM executes may be referred to as aphysical host and/or a host machine. For example, appliance 200 may beadditionally or alternatively implemented in a virtualized environment400 on any computing device, such as a client 102, server 106 orappliance 200. Virtual appliances may provide functionality foravailability, performance, health monitoring, caching and compression,connection multiplexing and pooling and/or security processing (e.g.,firewall, VPN, encryption/decryption, etc.), similarly as described inregard to appliance 200.

Additional details of the embodiment and operation of virtualizedcomputing environment 400 may be as described in U.S. Pat. No.9,538,345, issued Jan. 3, 2017 to Citrix Systems, Inc. of FortLauderdale, Fla., the teachings of which are hereby incorporated hereinby reference.

In some embodiments, a server may execute multiple virtual machines 406,for example on various cores of a multi-core processing system and/orvarious processors of a multiple processor device. For example, althoughgenerally shown herein as “processors” (e.g., in FIGS. 1C, 2 and 3), oneor more of the processors may be implemented as either single- ormulti-core processors to provide a multi-threaded, parallel architectureand/or multi-core architecture. Each processor and/or core may have oruse memory that is allocated or assigned for private or local use thatis only accessible by that processor/core, and/or may have or use memorythat is public or shared and accessible by multiple processors/cores.Such architectures may allow work, task, load or network trafficdistribution across one or more processors and/or one or more cores(e.g., by functional parallelism, data parallelism, flow-based dataparallelism, etc.).

Further, instead of (or in addition to) the functionality of the coresbeing implemented in the form of a physical processor/core, suchfunctionality may be implemented in a virtualized environment (e.g.,400) on a client 102, server 106 or appliance 200, such that thefunctionality may be implemented across multiple devices, such as acluster of computing devices, a server farm or network of computingdevices, etc. The various processors/cores may interface or communicatewith each other using a variety of interface techniques, such as core tocore messaging, shared memory, kernel APIs, etc.

In embodiments employing multiple processors and/or multiple processorcores, described embodiments may distribute data packets among cores orprocessors, for example to balance the flows across the cores. Forexample, packet distribution may be based upon determinations offunctions performed by each core, source and destination addresses,and/or whether: a load on the associated core is above a predeterminedthreshold; the load on the associated core is below a predeterminedthreshold; the load on the associated core is less than the load on theother cores; or any other metric that can be used to determine where toforward data packets based in part on the amount of load on a processor.

For example, data packets may be distributed among cores or processesusing receive-side scaling (RSS) in order to process packets usingmultiple processors/cores in a network. RSS generally allows packetprocessing to be balanced across multiple processors/cores whilemaintaining in-order delivery of the packets. In some embodiments, RSSmay use a hashing scheme to determine a core or processor for processinga packet.

The RSS may generate hashes from any type and form of input, such as asequence of values. This sequence of values can include any portion ofthe network packet, such as any header, field or payload of networkpacket, and include any tuples of information associated with a networkpacket or data flow, such as addresses and ports. The hash result or anyportion thereof may be used to identify a processor, core, engine, etc.,for distributing a network packet, for example via a hash table,indirection table, or other mapping technique.

Additional details of the embodiment and operation of a multi-processorand/or multi-core system may be as described in U.S. Pat. No. 9,538,345,issued Jan. 3, 2017 to Citrix Systems, Inc. of Fort Lauderdale, Fla.,the teachings of which are hereby incorporated herein by reference.

Although shown in FIGS. 1A and 1B as being single appliances, appliances200 may be implemented as one or more distributed or clusteredappliances. Individual computing devices or appliances may be referredto as nodes of the cluster. A centralized management system may performload balancing, distribution, configuration, or other tasks to allow thenodes to operate in conjunction as a single computing system. Such acluster may be viewed as a single virtual appliance or computing device.FIG. 4 shows a block diagram of an illustrative computing device clusteror appliance cluster 600. A plurality of appliances 200 or othercomputing devices (e.g., nodes) may be joined into a single cluster 600.Cluster 600 may operate as an application server, network storageserver, backup service, or any other type of computing device to performmany of the functions of appliances 200 and/or 205.

In some embodiments, each appliance 200 of cluster 600 may beimplemented as a multi-processor and/or multi-core appliance, asdescribed herein. Such embodiments may employ a two-tier distributionsystem, with one appliance if the cluster distributing packets to nodesof the cluster, and each node distributing packets for processing toprocessors/cores of the node. In many embodiments, one or more ofappliances 200 of cluster 600 may be physically grouped orgeographically proximate to one another, such as a group of bladeservers or rack mount devices in a given chassis, rack, and/or datacenter. In some embodiments, one or more of appliances 200 of cluster600 may be geographically distributed, with appliances 200 notphysically or geographically co-located. In such embodiments,geographically remote appliances may be joined by a dedicated networkconnection and/or VPN. In geographically distributed embodiments, loadbalancing may also account for communications latency betweengeographically remote appliances.

In some embodiments, cluster 600 may be considered a virtual appliance,grouped via common configuration, management, and purpose, rather thanas a physical group. For example, an appliance cluster may comprise aplurality of virtual machines or processes executed by one or moreservers.

As shown in FIG. 4, appliance cluster 600 may be coupled to a firstnetwork 104(1) via client data plane 602, for example to transfer databetween clients 102 and appliance cluster 600. Client data plane 602 maybe implemented a switch, hub, router, or other similar network deviceinternal or external to cluster 600 to distribute traffic across thenodes of cluster 600. For example, traffic distribution may be performedbased on equal-cost multi-path (ECMP) routing with next hops configuredwith appliances or nodes of the cluster, open-shortest path first(OSPF), stateless hash-based traffic distribution, link aggregation(LAG) protocols, or any other type and form of flow distribution, loadbalancing, and routing.

Appliance cluster 600 may be coupled to a second network 104(2) viaserver data plane 604. Similarly to client data plane 602, server dataplane 604 may be implemented as a switch, hub, router, or other networkdevice that may be internal or external to cluster 600. In someembodiments, client data plane 602 and server data plane 604 may bemerged or combined into a single device.

In some embodiments, each appliance 200 of cluster 600 may be connectedvia an internal communication network or back plane 606. Back plane 606may enable inter-node or inter-appliance control and configurationmessages, for inter-node forwarding of traffic, and/or for communicatingconfiguration and control traffic from an administrator or user tocluster 600. In some embodiments, back plane 606 may be a physicalnetwork, a VPN or tunnel, or a combination thereof.

Additional details of cluster 600 may be as described in U.S. Pat. No.9,538,345, issued Jan. 3, 2017 to Citrix Systems, Inc. of FortLauderdale, Fla., the teachings of which are hereby incorporated hereinby reference.

B. Using Advanced Network Analytics To Classify Transport LayerConnections

The present disclosure is directed towards systems and methods forclassifying transport layer connections, for instance, TCP connections,in terms of network type and estimating network conditions. The presentsolution examines network packets transmitted over TCP connections togenerate various metrics relating to network performance. Based on thesemetrics, the network type of the TCP connection is inferred and then thesignal quality and congestion level of the network can be determined innear-real time.

The network type and network conditions experienced by mobile users canbe accurately inferred by inspecting the TCP packets anywhere in betweenthe connection's endpoints. Particularly, in mobile wireless networks,the radio access technology (e.g. 2G, 3G & 4G) can be inferred and theperceived network congestion (e.g. None, Medium, High) and signalquality (e.g. Excellent, Good, Poor) can be perceived. This disclosureincludes a novel design of a machine learning pipeline for inferring theradio access type of TCP connections with high accuracy. This disclosurealso includes elegant modeling of congestion and signal quality inmobile wireless networks, as well as non-intrusive monitoring of TCPconnections for producing advanced network analytics.

In the realm of mobile wireless networks, the degraded performance ofTCP is a well-known problem, as are its causes. However, the complexityand dynamics of TCP, in conjunction with the various radio linktechnologies used in mobile wireless networks, hinder the establishmentof a solid model that accounts for the perceived performance of a TCPconnection. This disclosure models the complex interactions of TCP withthe underlying radio access technologies and provides a comprehensiveinsight of the network in terms of performance and radio access types.As a result, the solutions provided in this disclosure allow the overallbehavior of the network to be analyzed, in terms of the conditionsexperienced by mobile subscribers. In the context of this use case,entities (e.g., cellular network service providers, content providerswho distribute content via a cellular network, etc.) can leverage thisfeature for network analysis, using the analytics for forward planning.Entities also can use the solutions provided in this disclosure formarket analysis by tracking success in user adoption or churn for userswith different devices and network types. In addition, this disclosureprovides solutions that can adapt a TCP profile, independently for eachsubscriber and in near-real time, based on their current networkconditions. In the context of this use case, an entity can use thisfeature to improve user experience by detecting wireless network typeand radio characteristics for configuring the optimal TCP profile peruser device. An entity also can use this feature for policy drivenactions, which can allow service and content providers to make decisionsbased on user experience (e.g., smaller files for more constrainedusers).

Adaptive TCP as described in this disclosure is likely to becomeincreasingly important in the future, mainly because of the increase ofthe average TCP connection size (in terms of bytes or duration) and theadoption of new network technologies. Given that, congestion controlalgorithms should maintain their efficiency for even more networktechnologies. Providing comprehensive network analytics in a centralizedand non-intrusive fashion renders the solutions of this disclosure moreappealing compared to distributed, probe-based solutions, which aretraditionally more expensive and harder to administrate.

Now referring to FIG. 5, a diagram of an embodiment of a mobile wirelesscomputing environment 700 is shown. The network path in the computingenvironment 700 flows from right to left, and includes a networkanalytics system 705. The degraded performance of TCP connection in thecomputing environment 700 is primarily caused by the last hop—namely theradio access link. Whether this is due to poor signal conditions (datacorruption) or network load (bottleneck), both phenomena are expressedas an increase in round trip time (RTT). However, to optimize theperformance of TCP on such networks it is cardinal to distinguishbetween these two phenomena. The solutions of the present disclosureprimarily focus on the last hop of the depicted network path, which isbetween the antenna and the mobile UE shown on the left-hand side ofFIG. 5. Particularly, this disclosure concerns the way the base stationtransmits data to the UE.

Referring now to FIG. 6, the wireless protocol stack 710 for LTE andWCDMA pertinent to the user plane is shown. The wireless protocol stack710 illustrates the protocols that span the entire path between themobile UE and the internet and those that do not (marked with asterisk“*” in FIG. 6). Among these protocols, the MAC and RLC in Data LinkLayer are of particular interest for this disclosure, because these twoprotocols implement error detection and recovery techniques for thetransmitted user data. The data recovery is achieved by means ofretransmission. The processes that implement this functionality in RLCand MAC layers are ARQ and HARQ, respectively. FIG. 7A depicts anexample process 720 that illustrates the HARQ mechanism in case of LTE.Whenever a corrupted data packet is received, a series ofretransmissions occur resulting in delays that are relayed to the TCPlayer above. Each retransmission takes a specified time to complete,which is defined by the protocol standard. The nature of this type ofdelays is sporadic, random, and spiky.

FIG. 7B depicts a plot 730 showing the packet delays in a TCPconnection. In the plot 730 there are a few pronounced spikes in packetdelay (marked with dots), which are a result of (H)ARQ retransmissions.The area in the plot 730 colored in red is the estimated effect of thesewireless retransmissions, while the area colored in green is theestimated effect of congestion. Congestion is the result of service andqueuing delays introduced by the Proportional Fair Scheduling (PFS)algorithm when the requested resources (bandwidth) exceed the availableshared link capacity. The nature of this type of delay is small,constant, and increasing. An example Proportional Fair Scheduler 740 isshown in FIG. 7C.

Advanced PFS algorithms assign resources to the mobile UEs everyTransmission Time Interval (TTI). The resource allocation is donedynamically taking into account the overall subscribers' demand and thenetwork conditions experienced by each of them. The value of TTI is partof the protocol's specification, which is set to 1 ms for LTE and 2 msfor WCDMA. Each time the PFS algorithm decides not to schedule aparticular subscriber, the packets of that specific subscriber arequeued and the delay is increased one TTI. In other words, the temporaldistance of consecutive packets, namely inter-sending/arrival interval,increases one TTI.

FIG. 7D depicts a plot 750 showing the cumulative distribution function(CDF) of inter-arrival/sending intervals of packets for a LTEconnection. In this example, a relatively large amount of packets(almost 20%) having an inter-arrival interval of 1 ms are shown, as isanother group of packets having an inter-arrival interval of 7 ms. Thelatter is exhibited when HARQ retransmissions occur. The observedinter-arrival interval of 7 ms is in-line with the theoretical time of aHARQ retransmission. FIG. 7E depicts a plot 760 showing the respectiveCDF of a WCDMA connection. In this example, the first spike is locatedat 2 ms inter-arrival interval, which is the TTI of WCDMA, and thesecond spike is located at 10 ms, which is the time of a HARQretransmission in WCDMA.

The systems and methods of this disclosure exploit the fact that TCPcaptures the peculiarities of the underlying protocols to infer thenetwork type and estimate the network conditions. More specifically, ahigh percentage of TCP packets with 1 ms inter-arrival intervalsprovides strong evidence that the underlying wireless network is LTE.Similarly, a high percentage of TCP packets with 2 ms inter-arrivalintervals is a strong indication that the underlying network is WCDMA.On the other hand, because the (H)ARQ retransmissions introduce aminimum delay, which is several times bigger (e.g., more than 7 ms) thanthe protocol's TTI, congestion can be distinguished from bad signalquality. The high-level description of the protocols' intervalsdiscussed above can be leveraged to produce elaborate insights for thenetwork under consideration, as discussed further below.

FIG. 8A is a block diagram of the network analytics system 705 shown inFIG. 5. In some embodiments, the network analytics system 705 can beused to classify TCP connections in terms of network type and toestimate network conditions for TCP connections. The system 705 includesa packet capturing engine 805, a packet analyzer 810, a data accumulator815, a data labeler 820, a model generator 825, a network typeclassifier 830, and a conditions ranking engine 835. Together, thesecomponents can collect and analyze network packets from TCP connections,and can provide insights into the types of those TCP connections and thenetwork conditions experienced by users associated with the TCPconnections. In some embodiments, the system 705 can be implemented asthe appliance 200 shown in FIGS. 1A-1D, which can be an applicationdelivery controller (ADC), for example. The system 705 can be used toimplement the methods 850, 870, 880, and 890 shown in FIGS. 8B, 8E, 8F,and 8G, respectively. Thus, the functionality of the system 705 isdescribed further below in connection with these methods.

Referring now to FIG. 8B, an example method 850 for generatingclassification models is shown. In brief overview, the method 850includes capturing a plurality of network packets from a plurality ofTCP network connections (step 852), analyzing the plurality of networkpackets to generate a plurality of metrics (step 854), collecting andconsolidating the generated metrics for all analyzed TCP networkconnections (step 856), clustering the generated metrics to assignlabels in terms of network type to the plurality of TCP connections(step 858), and generating classification models (step 860).

Referring again to FIG. 8B, the method 850 includes capturing aplurality of network packets from a plurality of TCP network connections(step 852). In some embodiments, this can be performed by the packetcapturing engine 805. For example, the packet capturing engine 805 canbe configured to receive a plurality of packets associated with aplurality of TCP connections or streams. Each stream or connection maybe associated with a different mobile device. For each packet, thepacket capturing engine 805 can generate and retain a copy of thepacket, while also forwarding the received packet on to its intendeddestination. In some embodiments, the packet capturing engine 805 alsocan determine a particular TCP connection associated with each packet.For example, the packet capturing engine 805 can determine suchinformation by examining a header included in each packet. Thus, thepacket capturing engine 805 can identify all of the packets that arereceived in connection with a given TCP connection, even if multiple TCPconnections are established within the system 705.

The method 850 also includes analyzing the plurality of network packetsto generate a plurality of metrics (step 854). In some embodiments, thisstep can be performed by the packet analyzer 810 shown in FIG. 8A. Themetrics generated in this step can be associated with a respective TCPstream or connection. Thus, the packet analyzer 810 can be configured togenerate a set of metrics for each TCP stream or connection for whichpackets are captured by the packet capturing engine 805. In someembodiments, for each TCP stream of connection, the packet analyzer 810can generate metrics related to any combination of average instantaneousthroughput, minimum, maximum and average RTT, average inter-sendingintervals of TCP packets, average inter-arrival intervals of TCPpackets, probability of 1 ms inter-arrival interval, probability of 2 msinter-arrival interval, average inter-arrival intervals in range (0-7ms), average inter-arrival intervals in range (7 ms-inf), average loaddelay, and average noise delay. In some embodiments, the packet analyzer810 can be configured to generate these metrics using a variety ofalgorithms, some of which are described further below in connection withFIGS. 9A-9C.

The method 850 also includes collecting and consolidating the generatedmetrics for all analyzed TCP network connections (step 856). In someembodiments, this step can be performed by the data accumulator 815shown in FIG. 8A. Generally, the data accumulator 815 can be configuredto collect all of the metrics for each TCP connection. For example, thedata accumulator 815 can store information relating to each of thegenerated metrics in a data structure that is associated with arespective TCP connection, so that the metrics and their correspondingTCP connections can be retrieved for further processing.

The method 850 also includes clustering the generated metrics to assignlabels to the plurality of TCP connections (step 858). This step can beperformed, for example, by the data labeler 820 shown in FIG. 8A. Insome embodiments, the data labeler 820 can leverage clustering methodsin order to overcome the obstacle of not having labeled training data.The data labeler 820 can generate such labeled data, which can be usedlater by the network type classifier 830.

FIG. 8C depicts a chart 863 showing the 2G connections clustered in redand the 3G and 4G connections in blue and green respectively. The datalabeler 820 can assign the “2G” label to the connections belonging inthe group with the highest average min RTT and label “Other” to thesecond group, as illustrated in FIG. 8C. In some embodiments, the datalabeler 820 can label the 2G connections with accuracy of about 99%.Subsequently, the data labeler 820 can implement data filteringfunctionality in which all connections marked as “2G” are filtered outand the group containing the 3G and 4G connections is kept. Then, thedata labeler 820 can repeat the same procedure in order to distinguishthe 3G connections from the 4G connections. In some embodiments, thedata labeler 820 can distinguish between 3G connections and 4Gconnections by using spectral clustering with the following attributes:average instantaneous throughput, minimum/maximum and average RTT,average inter-arrival intervals, average inter-sending intervals,probability of 1 ms inter-arrival interval, probability of 2 msinter-arrival interval, average inter-arrival intervals in range (0-7ms), average inter-arrival intervals in range (7 md-inf). FIG. 8Ddepicts a chart 865 showing how the 3G and 4G connections are separatedand identified by the data labeler 820 using only three metrics: averageinstantaneous throughput and probability of 1 ms inter-arrival interval,probability of 2 ms inter-arrival interval. In accordance with thedescription above, the data labeler 820 can assign the “3G” label to theconnections with the highest average min RTT and the “4G” label to theother group. In some embodiments, the accuracy of this functionality canbe about 98% on average.

The method 850 also includes generating classification models (step860). In some embodiments, this step can be performed by the modelgenerator 825 shown in FIG. 8A. In some embodiments, the model generator825 can generate a model by first training and testing a logisticregression model, in which the dependent variable is the network typeinferred in the previous step. In general, this step can be implementedas a multiclass classification problem in which the connections areclassified into two (or more) classes that can correspond to networktypes, such as “2G,” “3G,” “4G,” etc. The multiclass classificationproblem can be transformed into a set of binary classification problems,which may easier for the model generator 825 to solve and may facilitatethe adoption of additional classes in the future, such as “5G” and WiFi.Thus, this step can include identifying all of the TCP connections thatcorrespond to a first network type based on the generated metrics, anddetermining those TCP connections as corresponding to the first networktype. For example, if the TCP connections include 2G, 3G, and 4Gconnections, this step can form two groups of connections: a first groupcontaining 2G connections, and a second group containing non-2Gconnections (i.e., 3G and 4G connections together). In some embodiments,the model generator 825 can implement this step using a K-Meansalgorithm with two metrics, including average instantaneous throughputand minimum RTT. The logistic model can be used to predict the type of aconnection between “2G” or “Other.” Then, the model generator 825 canperform training and testing of a logistic regression model to predictthe type of a connection between “3G” and “4G.” This functionality canbe repeated as many times as needed, depending on the number ofdifferent network types. Thus, the model generator 825 can producemodels for distinguishing between all of the network types correspondingto the network packets received by the system 705.

FIG. 8E shows an example method 870 for inferring a network type,network conditions, and signal quality. As discussed above, in someembodiments, the method 870 also can be performed by the system 705shown in FIG. 8A. In brief overview, the method 870 includes capturing aplurality of network packets from a plurality of TCP network connections(step 872), analyzing the plurality of network packets to generate aplurality of metrics (step 874), inferring network types of theplurality of TCP connections based on the plurality of metrics and atleast one classification model (step 876), and estimating a level ofnetwork congestion and signal quality for each TCP connection based onthe plurality of metrics and the network types (step 878).

Referring again to FIG. 8E, the method 870 includes capturing aplurality of network packets from a plurality of TCP network connections(step 872) and analyzing the plurality of network packets to generate aplurality of metrics (step 874). It should be understood that thesesteps are substantially the same as steps 852 and 854 of the method 850shown in FIG. 8B and described above. Thus, these steps can be performedby the packet capturing engine 805 and the packet analyzer 810,respectively, shown in FIG. 8A.

The method 870 also includes inferring network types of the plurality ofTCP connections based on the plurality of metrics and at least oneclassification model (step 876). In some embodiments, this can beperformed by the network type classifier 830 shown in FIG. 8A. In someembodiments, the network type classifier 830 can take as input themetrics generated in the previous step, as well as the classificationmodels derived by the model generator 825 as part of the method 850shown in FIG. 8B. From this information, the network type classifier 830can infer the network type of each connection represented in the packetdata received by the packet capturing engine 805. In some embodiments,the network type classifier 830 determines a network type only for TCPconnections that have not been used to generate a model. Thus, trainingdata for the models can be separated from data that is used to infernetwork types based on the models.

The method 870 also includes estimating a level of network congestionand signal quality for each TCP connection based on the plurality ofmetrics and the network types (step 878). In some embodiments, this stepcan be performed by the conditions ranking engine 835 shown in FIG. 8A.The conditions ranking engine 835 can take as input the metrics and theclassification decision from the previous two steps and can estimate thelevel of congestion and signal quality for the connection based on theseinputs. In some embodiments, the conditions ranking engine 835 canestimate load and noise delays, normalize the load and noise delays, andcan generate signal quality and congestion rankings based on thenormalized load and noise delays.

FIG. 8F is a flowchart of an example method 880 for identifying a typeof network of a transport layer connection. As discussed above, in someembodiments, the method 880 also can be performed by the system 705shown in FIG. 8A. In brief overview, the method 880 includesestablishing metrics of network traffic traversing one or more devicesvia a plurality of transport layer connections (step 882). The method880 includes classifying, by a network classifier, the plurality oftypes of networks into a classification model (step 884). The method 880includes identifying, by the network classifier responsive to a devicereceiving one or more packets for a transport layer connection, a typeof network of the plurality of types of networks for the transport layerconnection (step 886).

Referring again to FIG. 8F, the method 880 includes establishing metricsof network traffic traversing one or more devices via a plurality oftransport layer connections (step 882). In some embodiments, this stepcan be performed by any of the a packet capturing engine 805, a packetanalyzer 810, a data accumulator 815, a data labeler 820, a modelgenerator 825, a network type classifier 830, and a conditions rankingengine 835 of the network analytics system 705. The plurality oftransport layer connections can provide communications with a pluralityof different types of networks. For example, the plurality of types ofnetworks can include mobile networks or fixed networks. In someembodiments, a mobile network can be a 2G, 3G, 4G or 5G network. If atleast one of the networks includes a mobile network, the transport layerconnection associated with the mobile network can be established with amobile device, such as a cellular phone or tablet computing device. Insome embodiments, the metrics can be established by capturing packetsfrom the network traffic of the plurality of transport layer connectionstraversing the one or more devices. For example, network packets may becaptured by the packet capturing engine 805 of the network analyticssystem 705.

The metrics established in step 882 can include any metrics relating tothe network traffic, such as average throughput, average instantaneousthroughput, average inter-arrival intervals, average inter-sendinginterval, maximum round trip time, minimum round trip time, averageround trip time, average load delay and average noise delay. In someembodiments, the metrics can include a percentage of packets of thenetwork traffic within a predetermined inter-arrival interval and aprobability of a packet having the predetermined inter-arrival interval.

The method 880 includes classifying, by a network classifier such as thenetwork type classifier 830 of FIG. 8A, the plurality of types ofnetworks into a classification model (step 884). In some embodiments,the classification model can be a model derived by the model generator825 as part of the method 850 shown in FIG. 8B. In some embodiments, thenetwork classifier can generate or establish a classification modelusing the metrics of the plurality of types of networks. The networkclassifier can classify different networks into at least of a pluralityof network types using the classification model. In some embodiments, alogistic regression model can be trained and tested, as described above.In some embodiments, the dependent variable for such a regression can bethe network type. Producing the model can be thought of as a multiclassclassification problem in which the connections are classified into two(or more) classes that can correspond to network types, such as “2G,”“3G,” “4G,” etc. The multiclass classification problem can betransformed into a set of binary classification problems. For example,if the TCP connections include 2G, 3G, and 4G connections, generatingthe model can include forming two groups of connections: a first groupcontaining 2G connections, and a second group containing non-2Gconnections (i.e., 3G and 4G connections together). In some embodiments,the network classifier 830 or the model generator 825 can implement thisstep using a K-Means algorithm with two metrics, including averageinstantaneous throughput and minimum RTT.

The method 880 also includes identifying, by the network classifierresponsive to a device receiving one or more packets for or via atransport layer connection, a type of network of the plurality of typesof networks for the transport layer connection (step 886). In someembodiments, the device can be a network analytics system such as thenetwork analytics system 705. In some embodiments, a component such asthe network type classifier can infer the type of network for thetransport layer connection by comparing the metrics of the one or morepackets to the classification model established by the networkclassifier for the plurality of types of networks in step 884. In someembodiments, the network classifier can also distinguish betweendifferent types of networks based on the various metrics established instep 882, such as the inter-arrival intervals of the network packets orthe average minimum round trip times of the network packets.

FIG. 8G is a flowchart of an example method 890 for determining networkcongestion and signal quality for a transport layer connection. Asdiscussed above, in some embodiments, the method 890 also can beperformed by the system 705 shown in FIG. 8A. In brief overview, themethod 890 includes establishing a classification model for a pluralityof types of networks (step 892). The method 890 includes receivingmetrics of a plurality of packets (step 893). The method 890 includesclassifying a type of network for a transport layer connection (step894). The method includes determining a level of congestion and a signalquality for the transport layer connection (step 895). The method 890also includes providing the level of congestion and the signal qualityfor the transport layer connection (step 896).

Referring again to FIG. 8G, the method 890 includes establishing aclassification model for a plurality of types of networks (step 892). Insome embodiments, this step can be performed by the network typeclassifier 830 of the system 705. The network type classifier 830 canestablish the model based on metrics of network traffic traversing oneor more devices (which may include the system 705) for a plurality oftransport layer connections providing communications with a plurality oftypes of networks. In some embodiments, packets included in the networktraffic can be captured, for example, by the packet capturing engine805. The classification model established in step 892 can be one of themodels generated by the model generator 825. In some embodiments, theplurality of types of networks can include a type of a mobile network ora type of a fixed network. For example, a mobile network type mayinclude a 2G, 3G, 4G, or 5G network.

The method 890 includes receiving metrics of a plurality of packets(step 893). In some embodiments, the packets can be included in atransport layer connection that facilitates transmittal of the networktraffic. The metrics can be received, for example, by the network typeclassifier 830. After the metrics have been received, the method 890includes classifying a type of network for a transport layer connection(step 894). This step can also be performed by the network typeclassifier 830. In some embodiments, the network type classifier 830 canclassify the type of network based on the metrics received in step 893.In some embodiments, classifying the network type can include inferringthe type of network by comparing the results of the one or moreclassification models generated by the model generator 825, or byanalyzing any other suitable metrics of the network traffic.

The method 890 includes determining a level of congestion and a signalquality for the transport layer connection (step 895). In someembodiments, this step can be performed by the conditions ranking engine835. For example, the conditions ranking engine can determine thecongestion and signal quality based on the metrics and theclassification of the network type. In some embodiments, the otherinformation can also be determined based on the metrics. For example, aload and noise delay per packet of the plurality of packets can bedetermined based on the metrics. In some embodiments, the method caninclude determining an average load delay and average noise delay forthe transport layer connection. For example, the average load delay andaverage noise delay can be determined by the packet analyzer 810. Inaddition, the packet analyzer 810 may also determine a relative averageload delay and a relative average noise delay with respect to an averageconnection delay for the transport layer connection.

In still other embodiments, the method 890 can include determining, bythe packet analyzer 810, an ideal throughput metric based on a number ofbytes transferred and excluding network congestion and noise. In someembodiments, the packet analyzer 810 can determine a degradationpercentage for the transport layer connection based on a function of theideal throughput metric and an average throughput of the transport layerconnection. In some embodiments, the packet analyzer 810 can determinethe level of congestion for the transport layer connection based on afunction of the ideal throughput metric and the load delay. In someembodiments, the packet analyzer 810 can determine the signal qualityfor the transport layer connection based on a function of the idealthroughput metric and the noise delay.

The method 890 also includes providing the level of congestion and thesignal quality for the transport layer connection (step 896). In someembodiments, the level of congestion and the signal quality can beprovided for display via a user interface, such as the user interface123 shown in FIG. 1C.

FIGS. 9A-9C illustrate algorithms that can be used to estimate load andnoise delays as part of the packet analysis steps 854 and 874 of themethods 850 and 870, respectively, which are described above. Onalgorithm for estimating these two delays can begin by definingvariables as follows:

-   -   net_rtt:corresponding minimum rtt for 3G and 4G    -   ist(n):packet's n sent time    -   iat(n):packet's n arrival time    -   iai(n+1)=iat(n+1)−iat(n)    -   isi(n+1)=ist(n+1)−ist(n)    -   delay(n+1)=delay(n)+iai(n+1)−isi(n+1)    -   For n=0, delay(0)=rtt−net_rtt

Next, buffer delays can zero out inter-sending intervals, and timewindow of timing compressed packets can be formed, as illustrated in thediagram 900 of FIG. 9A with reference to the variables defined above.Referring to the diagram 910 FIG. 9B, functionality for initializing thewindow referred to above is illustrated. In general, the followingvariables can be defined in connection with this functionality:

-   -   wnd_start=ist(n), n is a radio retransmitted packet    -   wnd_knee=wnd_start+load_delay(n)    -   wnd_end=wnd_knee+harq_delay(n)

The window can then be updated according to the following functionality,which is illustrated in the diagram 920 of FIG. 9C:

-   -   if ist(m)<wnd_knee, m is another radio retransmitted packet    -   wnd_knee+=load_delay(m)    -   wnd_end+=harq_delay(m)

Next, packet delay splitting can be achieved according to the followingsteps:

  delay(n + 1) = delay(n) + iai(n + 1) − isi(n + 1)  delay(n + 1) = harq_delay(n + 1) + load_delay(n + 1)${{harq\_ delay}\left( {n + 1} \right)}+=\left\{ {{\begin{matrix}{{{{iai}\left( {n + 1} \right)} - {is{i\left( {n + 1} \right)}}},{{if} \geq {HARQ\_ THRESHOLD}}} \\{{\delta\left( {n + 1} \right)},{otherwise}}\end{matrix}\mspace{20mu}{load\_ delay}\left( {n + 1} \right)}+=\left\{ {{\begin{matrix}{0,{{if} \geq {HARQ\_ THRESHOLD}}} \\{{{{delay}\left( {n + 1} \right)} - {\delta\left( {n + 1} \right)}},{otherwise}}\end{matrix}\mspace{20mu}{\delta(n)}} = \left\{ {{\begin{matrix}{0,{{{ist}(n)} \geq {wnd\_ end}}} \\{{{wnd\_ end} - {wnd\_ knee}},{{{ist}(n)} < {wnd\_ knee}}} \\{{{wnd\_ end} - {{ist}(n)}},{{{ist}(n)} \geq {wnd\_ knee}}}\end{matrix}\mspace{20mu}{HARQ\_ THRESHOLD}} = {{0.007\mspace{14mu}\sec}//{{default}\mspace{14mu}{value}}}} \right.} \right.} \right.$

Finally, relative packet delay estimation can be achieved by thefollowing functionality:

-   -   load_delay_pct=avg(load_delay)/avg(delay)    -   noise_delay_pct=avg(harq_delay)/avg(delay)

The above algorithm estimates the absolute congestion and noise delaysper packet, as well as the percentage of average delays for the entireconnection. To enable the comparison between connections of differentsize in terms of congestion and noise, a normalization process can beused. This process can take into account the bytes transferred in orderto estimate the maximum possible throughput that the connection couldachieve if the network conditions were ideal (i.e., if there were nocongestion and no noise). That metric can be referred to as idealthroughput.

To estimate the ideal throughput, a nonlinear regression model can beused to approximate the maximum possible throughput on a particularchannel (3G or 4G), given the transferred bytes. The plot 1000 shown inFIG. 10A depicts the fitted curve line over a number of connections. Thecurve line of the plot 1000 has the form y=min(a*log(b*(x+c))+d, e),where “x” is the independent variable representing the transferred bytesand “e” represents the channels bandwidth.

The ideal throughput can be used to calculate the total degradationpercentage of throughput due to the network conditions. In this way,percentages (i.e., normalized values) can be used rather than absolutevalues, which can complicate the comparison of connections withdifferent sizes. By combining the findings in the last two steps, theuser perceives congestion and signal quality as follows:

-   -   Connection Degradation Percentage:        CDP=(ideal_throughput−avg(throughput))/ideal_throughput    -   Connection Congestion Level: CCL=CDP*load_delay_pct    -   Connection Signal Quality: CSQ=CDP*harq_delay_pct

The resulted model, depicted in the plot 1010 of FIG. 10B, shows howcongestion and noise affects the connections' performance. In the plot1010, the x-axis represents the congestion level (CCL) and the y-axisrepresents the signal quality (CSQ). Each dot represents a file downloadover a single TCP connection. The dots are colored based on the achievedaverage throughput while the size of each dot represents the total bytestransferred (i.e., the connection length). Using the plot 1010, anyconnection can be compared, no matter what the number of transferredbytes was.

Thus, the present disclosure describes techniques to extract advancedand detailed insight, in terms of the network conditions experienced bya mobile subscriber, for the purpose of enabling the operator to analyzethe overall behavior of their network (network analytics), but also toautomatically adapt the traffic management actions of an applicationdelivery controller (ADC) to these conditions. As a by-product, thesystems and methods of the disclosure will extend the TCP-levelstatistics captured by the ADC. This can allow entities to utilizedetailed TCP-level information to make routing/policy based decisions.

Based on the above, this disclosure can enable two main use cases.First, the overall behavior of the network can be analyzed, in terms ofthe conditions experienced by mobile subscribers. An importantassumption is that the capability will be deployed as close as possibleto the mobile network. However, this doesn't preclude a deployment onthe content delivery network (CDN) or content provider side, but theinference models may become sensitive to issues elsewhere in the path.In the context of this use case, entities can leverage this feature fornetwork analysis to leverage analytics for forward planning, as well asfor market analysis to track success in user adoption or churn for userswith different devices and network types.

In a second use case enabled by this disclosure, the technology canallow entities to adapt the TCP profile, independently for eachsubscriber and in near-real time, based on their current networkconditions. In the context of this use case, entities can leverage thisfeature for: improving user experience by detecting wireless networktype and radio characteristics for configuring the optimal TCP profileper user device. Entities can also use policy driven actions, which canallow service and content providers to make decisions based on userexperience (e.g., smaller files for more constrained users).

The techniques described in this disclosure can provide a variety offunctionality in connection with mobile networks using TCP connections.For example, the systems and methods of the disclosure can enable theability to measure for both optimized proxied and non-proxied traffic.The systems and methods of the disclosure also can enable simultaneousidentification on a per-subscriber basis of the following connectionstates:

-   -   a. Congestion Level (either yes/no, or no, low, high).    -   b. Network Speed (slow, medium, fast)    -   c. Quality of Connection (good/poor)

The systems and methods of the disclosure also can enable UDP/TCPtraffic to be utilized for measurements to support reporting and drivingoptimization decisions (including proxying of traffic). In someembodiments, such measurements do not interfere (or at least minimallyinterfere) with TCP/UDP performance.

However, there may be instances in which the functionality of thesystems and methods of the disclosure deviate from that described above.For example, since this technology processes traffic at L4, thisdisclosure assumes the use of at least a “TCP” virtual server (vserver),which implies that only proxied traffic will be processed. In someembodiments, both ENDPOINT & TRANSPARENT modes are supported.

For the case of network speed, radio access types can be identified withgood accuracy. Instead of slow, medium, and fast, the systems andmethods of this disclosure can detect 2G, 3G, 4G; but the embodimentsare flexible enough to identify fixed (ADSL/VDSL, DOCSIS), WiFi,Satellite, 5G, etc. bearers in the future.

For the case of congestion level, the systems and methods of thisdisclosure can characterize it using four classes, namely None, Low,Medium, and High.

For the case of signal quality of connection, the systems and methods ofthis disclosure can characterize it using four classes as well, namelyExcellent, Good, Fair, Poor.

Taking into account deviations above, the functionality of the systemsand methods of this disclosure can be adapted as follows. The systemsand methods of this disclosure can provide the ability to measure fortraffic processed at Layer 4 (TCP), either in ENDPOINT or TRANSPARENTmode. The systems and methods of this disclosure can allow simultaneousidentification on a per-subscriber basis of the following connectionstates:

-   -   Network Speed (2G, 3G, 4G)    -   Congestion Level (None, Low, Medium, High)    -   Quality of Connection (Excellent, Good, Fair, Poor)

The systems and methods of this disclosure can utilize all TCP trafficfor measurements. Such measurements can be used for reporting and fordriving optimization decisions.

The models and algorithms for generating the inference results can makeuse of the introduction of new input fields to the L4 transactionalrecords generated by an ADC. Of particular interest are intervals of TCPsessions where there is an active transmission of data, in the directionfrom the ADC to the end-user (mobile terminal).

At a high level, the systems and methods of this disclosure can identifyintervals when there is active data transfer and reports the belowfields for the most significant of them (actually separately for eachdirection):

-   -   NSIPFIX_BURST_DURATION_MSEC_{RX|TX}        -   The duration (in msec) of the data transfer    -   NSIPFIX_BURST_OCTET_COUNT_{RX|TX}        -   The total number of octets (bytes) transmitted    -   NSIPFIX_BURST_RETRANS_OCTET_COUNT_{RX|TX}        -   The number of retransmitted octets (bytes)

The above fields are generated upon the end of the TCP session. Theycorrespond to the largest burst of the TCP session. Only bursts largeenough are meaningful.

The list of TCP metrics that can be exported in L4 transactional recordsis below. Export of these values can take place, for example, every 60secs, or when the byte counter overflows.

TCP information Remarks 4-tuple of the connection exported for both rxand tx side Packet count for the interval (i.e., exported for both rxand tx side delta value) on the connection Byte count in the interval onthe exported for both rx and tx side connection TCP flags: OR value ofthe flags For RX-template, the flags for the given connection receivedand for TX-template, the flags sent out will be indicated. Connectionchain ID and hop-count exported for both rx and tx side Number ofzero-windows received reported for rx side in the interval for theconnection Number of retransmissions that reported for tx side occurredin the interval on that connection No of fast retransmissions thatreported for tx side occurred in the interval on the connection Numberof times retransmission- reported for tx side timeout was hit in theinterval on the connection RTT value for the interval on that reportedfor tx side connection SRTT value for the interval on that reported fortx side connection Jitter value reported for tx side

The templates that carry these information elements, and the respectivefields, can be as follows:

TCP ingress template for Rx side—

-   -   NSIPFIX_SRC_IPV4_ADDR_RX    -   NSIPFIX_DST_IPV4_ADDR_RX    -   NSIPFIX_SRC_TRANSPORT_PORT_RX    -   NSIPFIX_DST_TRANSPORT_PORT_RX    -   NSIPFIX_PACKET_TOTAL_COUNT_RX    -   NSIPFIX_OCTET_TOTAL_COUNT_RX    -   NSIPFIX_TCP_FLAGS_RX    -   NSIPFIX_CONN_CHAIN_ID    -   NSIPFIX_CONNECTION_CHAIN_HOP_COUNT    -   NSIPFIX_ZERO_WINDOW_COUNT

TCP egress template for Tx side—

-   -   NSIPFIX_SRC_IPV4_ADDR_TX    -   NSIPFIX_DST_IPV4_ADDR_TX    -   NSIPFIX_SRC_TRANSPORT_PORT_TX    -   NSIPFIX_DST_TRANSPORT_PORT_TX    -   NSIPFIX_PACKET_TOTAL_COUNT_TX    -   NSIPFIX_OCTET_TOTAL_COUNT_TX    -   NSIPFIX_TCP_FLAGS_TX    -   NSIPFIX_ROUND_TRIP_TIME    -   NSIPFIX_SRTT    -   NSIPFIX_FAST_RETX_COUNT    -   NSIPFIX_CONN_CHAIN_ID    -   NSIPFIX_CONNECTION_CHAIN_HOP_COUNT    -   NSIPFIX_PACKET_RETRANSMIT_COUNT    -   NSIPFIX_RTO_COUNT    -   NSIPFIX_JITTER

However, the specific fields are calculated for incremental time periodsof TCP sessions, whereas this disclosure is primarily concerned withperiods of active transmission.

In some embodiments, transactional records generated by an ADC inaccordance with this disclosure as a result of processing TCP sessionscan be extended with new info fields. In some embodiments, the new infofields are generated for periods of active TCP data transmission,specifically from the ADC platform towards the device (UE) of a mobilesubscriber. In some embodiments, for decreasing the complexity of theembodiment and decreasing the amount of information that is generated,the new info fields are only be added to end of transaction (EOT)records, and only cover the most active period of data transfer. In someembodiments, the new info fields are transferred from the ADC to MASover the LogStreaming transport. The maximum acceptable capacity impactcan be about 10%. In some embodiments, for enabling the classificationmodels and inference algorithms described herein, the raw metrics belowcan be included:

-   -   rtt_min, rtt_avg: Minimum and Average RTT    -   bif_avg: Average bytes-in-flight    -   thrput_avg: Average throughput    -   isi_avg: Average packet inter-sending interval    -   iai_avg: Average packet inter-arrival interval    -   iai_1ms: Percentage of packets with inter-arrival interval 1        ms±10 μs    -   iai_2ms: Percentage of packets with inter-arrival interval 2        ms±10 μs    -   harq_delay: Delay of packets that suffered from RLC        retransmissions    -   load_delay: Delay of packets that suffered from network        congestion    -   rwnd_min, rwnd avg: Minimum and Average Receive Window    -   ack_cnt: Number of ACKs

In terms of metadata, the following field can be added:

-   -   tcp_profile: Name or identifier of TCP profile

In some embodiments, the following composite metrics can be included:

-   -   net_cls: The network type resulting from applying network type        classification    -   ccl, ccl_cls: The Connection Congestion Level (CCL) estimated by        the relevant inference algorithm, as well as the respective        class (None, Low, Medium, High)    -   csq, csq_cls: The Connection Signal Quality (CSQ) estimated by        the relevant inference algorithm, as well as the respective        class (Excellent, Good, Fair, Poor)

In some embodiments, calculating the above composite metrics requiresthe input parameters below, which can be a result of training theclassification models and inference algorithms:

-   -   Classification model coefficients: Separately for 2G vs rest and        for 3G vs 4G    -   net_rtt, harq_threshold: Separately for 3G and 4G (empirically        determined)    -   Ranking boundaries: Separately for 3G and 4G and for CCL and CSQ        scores

In some embodiments, the following raw metrics can be included:

-   -   rtt_max: Maximum RTT    -   bif_max: Maximum bytes-in-flight    -   packet_cnt/retx_packet_cnt: Total packets        transmitted/retransmitted    -   ooo_packet_cnt/ooo_octet_cnt: Total out-of-order packets/bytes    -   bdp_avg: Average bandwidth-delay product

The term Bandwidth as used in this disclosure defines the net bit rate(i.e., the peak bit rate, information rate, or physical layer useful bitrate), channel capacity, or the maximum throughput of a logical orphysical communication path in a digital communication system.

Bandwidth in bit/s may occasionally refer to consumed bandwidth,corresponding to achieved Throughput or “Goodput”, i.e., the averagerate of successful data transfer through a communication path.

Channel bandwidth may be confused with useful data throughput (orgoodput). By definition, useful/effective throughput is less than orequal to the actual channel capacity plus embodiment overhead. A networkelement depending on passive measurements can calculate throughput, butit can only infer/estimate bandwidth.

Network speed as referred to in this disclosure denotes the bandwidththat a network technology is able to deliver. Network speed is typicallyinversely correlated to network latency, i.e. networks that offer highspeed are characterized by low latency, and vice-versa. Intuitively,network speed depends on latency, but not as it may increase as a resultof high congestion or poor connection. Similarly, network speed dependson throughput, but not as it may degrade as a result of networkcongestion or poor signal quality. In that sense, network speed levelswill have a rough correlation to radio access types.

Network congestion is the situation in which an increase in datatransmission results in a proportionately smaller increase, or even areduction, in throughput. Network congestion occurs when a link or nodeis carrying so much data that its quality of service deteriorates.Typical effects include queueing delay, packet loss or the blocking ofnew connections. A consequence of the latter two effects is that anincremental increase in offered load leads either only to a smallincrease in network throughput, or to an actual reduction in networkthroughput. Intuitively, network congestion can be associated to anincrease in latency (RTT), but one that is considered to have adverseeffects in QoE. Also, highly correlated packet loss can be an indicationof network congestion, but only if it perseveres.

Connection quality as referred to in this disclosure denotes thecondition of the layer 1 connection between user equipment (UE) and theassociated radio cell(s). This is influenced by many factors, such ascellular network coverage, distance/path between the UE and theantenna(s), radio interference, signal/noise levels, power/RRC statepromotions/demotions, handovers between cells, indoors vs outdoors, etc.Intuitively, connection quality is associated to random packet loss andmomentary increases of network delay. In that sense, it can be desirableto discriminate between the reduction of network throughput that iscaused by high network congestion from the one that is caused from badconnection quality. Similarly, connection quality is disassociated fromnetwork speed, as defined herein (which refers to potential bandwidth),and is measured separately for each RAT.

In some embodiments, the systems and methods of this disclosure canimplement a classification model that discriminates between differentnetwork speeds. The model can classify mobile subscriber sessions intothree classes (2G, 3G, 4G), corresponding roughly to the respectiveradio access types.

Given that different mobile network technologies implement differentunderlying radio access types, the above class labels can correspond to:

-   -   2G: GSM (GRPS/EDGE), CDMA, 1xRTT    -   3G: WCDMA (UMTS, HSDPA, HSPA, HSPA+), CDMA2000 (EVDO, eHRPD)    -   4G: LTE, LTE-Advanced

Having said the above, the feature embodiment can be flexible toidentify fixed (ADSL/VDSL, DOCSIS), WiFi, Satellite, 5G, etc. bearers inthe future.

In some embodiments, subscriber sessions can be characterized further interms of the congestion level of the network path between the ADCplatform and the device. This characterization can involve thecalculation of a congestion level score, and subsequently the segmentingof this score into four (4) rankings, namely None, Low, Medium, andHigh.

In some embodiments, subscriber sessions can be additionallycharacterized in terms of the signal quality of the physical (radio)link between the base station and the device. This characterization caninvolve the calculation of a signal quality score, and therefore thesegmenting of this score into four (4) rankings, namely Excellent, Good,Fair, Poor.

In some embodiments, the congestion level and signal quality scores andrankings are required only for data sessions that have been classifiedas 3G or 4G network type. In some embodiments, only data segmentstransferred in the downstream direction may be relevant for the aboveclassification and characterization, and only ones that use TCP as thetransport layer protocol. This is due to the fact the models andalgorithms depend on the presence of acknowledgments (TCP ACK packets).In some embodiments, the generation of the input fields described aboveand inference results described above only take place when an ADCprocesses traffic at Layer 4 (TCP), and specifically in ENDPOINT mode.This restriction stems from the fact the input fields can be more easilygenerated when TCP sessions are handled by ADC congestion handlers. Insome embodiments, the generation of these input fields and inferenceresults can also take place when the ADC processes traffic at Layer 4(TCP) in TRANSPARENT mode, but this is probably not in the scope of theinitial embodiment.

One goal of generating the input fields and inference results describedabove is to enable a new set of MAS Analytics reports that can convey apicture of network-wide conditions to an entity (mobile service provideror mobile network operator). FIGS. 11A-11D provide a sample collectionof such reports. In some embodiments, the reports can provide atime-based (hourly) & aggregate (daily) measurement of the percentage ofsessions or downloads, as characterized by congestion level and signalquality rankings, and separately for 3G and 4G. FIG. 11A representsthose as 100% stacked bar charts, colored by the congestion level/signalquality ranks. In some embodiments, the reports can provide arepresentation of how user experience varies, depending on thecongestion level and signal quality, separately for 3G and 4G. Userexperience metrics can include “Goodput”, but may also include Latency,Buffer-bloat and Packet-loss (FIG. 11B represents those as a 4×4heat-map, each cell corresponding to a congestion level/signal qualityranking combination, colored and labeled per the user experience metricof interest).

In some embodiments, to facilitate comparative evaluation of differentTCP configurations, user experience metrics can be further analyzed on aper TCP profile name basis, but only for TCP profiles that areconfigured globally/per vserver, or via AppQoE policies. FIG. 11Crepresents those as bar charts. In some embodiments, these metrics couldalso be represented as crosstabs accompanying a heatmap such as theheatmap shown in FIG. 11B). In some embodiments, deeper analysis of perTCP profile performance can be achieved through introducing advanced TCPstatistics reports, namely:

Line Graphs

-   -   1) Minimum/Average/Maximum RTT over Time    -   2) Bandwidth-Delay-Product and Average/Maximum Bytes-in-Flight        over Time    -   3) Packet Loss Rate and Packet Retransmission Rate over Time    -   4) Buffer Delay Percentage over Time

Histograms

-   -   1) Minimum RTT by Count    -   2) Average RTT by Count    -   3) Maximum RTT by Count    -   4) Average BDP by Count    -   5) Average BIF by Count    -   6) Maximum BIF by Count    -   7) TCP Efficiency Percentage

In some embodiments, if location information is available, eitherthrough control-plane interfaces (Diameter/Gx or RADIUS) or throughGeo-IP database lookups (which in some embodiments may not be veryrelevant to the mobile operator use case), maps that provideper-location view of the above metrics and inference results can beprovided. FIG. 11D provides a sample showing average throughput. In someembodiments, a similar map could be generated to show Congestion LevelScore or Signal Quality Score by Location.

Another goal of classifying the network type and generating theinference results described above is to automate the configuration andtuning of the TCP profiles of an ADC. This aims to remove the burden ofhaving to manually accomplish this, every time the customer needs toprepare for the next trial, tuning, or benchmarking exercise.

Moreover, this aims to produce better TCP optimization results, giventhat there is really not a single TCP profile that is optimal for theentire range of network types, congestion levels and signal qualities.By automatically selecting or adapting the TCP profile per theclassified network type and characterized network conditions, theresulting overall TCP optimization performance will be better thansetting a global TCP optimization profile.

In some embodiments, the outcome of network type classification can beavailable as an ADC policy condition, for selecting or tuning the TCPoptimization profile.

In some embodiments, congestion level and signal quality ranking can beavailable as ADC policy conditions, for selecting or tuning the TCPoptimization profile.

In some embodiments, these new policy conditions can allow selectingfrom a pre-determined set of TCP profiles, which can be designed tocover a broad range of network performance and conditions.

In some embodiments, the pre-determined set of TCP profiles can utilizethe internal parameters of TCP Nile.

In some embodiments, pre-determined TCP profile names can be stored asmetadata, albeit those may not be exposed in reports.

In some embodiments, for immediate reaction to network conditions, TCPprofile selection changes can be possible within the context of the sameTCP connection. Alternatively, TCP profile switching can take place uponthe next TCP connection.

In some embodiments, historical network type classification andcongestion/signal rankings can be maintained on a per subscriber basisfor a configurable amount of time. These will be used for the followingreasons:

a) Extend policy decisions across different TCP connections and packetengine instances.

b) Limit frequency of policy actions and avoid “flapping” of TCP profileselections.

In some embodiments, subscriber identification may not assume uniqueidentifiers. Historical classification/inference results can be storedat least on the basis of IP addresses, in which case TCP profileselection actions can apply across the connections of the same source IPaddress.

In some embodiments, performance evaluation reports can be madeavailable that would estimate relative improvement versus the scenario aglobal TCP profile is used. FIGS. 12A and 12B provide sample reports.

Systems and methods of this disclosure can employ machine learning (ML)models that depend on the MAS Telemetry Cluster architecture. Forexample, MAS Advanced Analytics can be able to ingest and processtransactional data (i.e. not only counters) carrying TCP information. Insome embodiments, even though most of the models described herein canuse the Python data analysis stack (NumPy, Pandas, SciKit-Learn, etc.),as datasets increase, the scalable data processing capabilities of Sparkmay also be leveraged.

In some embodiments, to bootstrap and re-train the machine learningmodels and algorithms, collections of observations can be accumulated,by extracting the required attributes from the transactional data sourceand storing them to a data store, where they can be easily accessed.Moreover, the models described herein can store state that will persistacross training runs, most importantly the trained parameters andevaluation results.

In some embodiments, while datasets are being accumulated in the datastore, a mechanism can be provided that will check on a recurring basiswhether an adequate number of observations has been gathered and thatwill initiate the bootstrapping/re-training of the models.

This disclosure describes two alternative designs, in terms of applyingthe trained models. In a first design, the models and algorithms can beexecuted on the ADC itself. This does not utilize the real-time path ofMAS Telemetry Cluster, and only involves sending updated modelparameters back to the ADC, only when model re-training results intochanges. In a second design, the real time (streaming) path of the MASTelemetry Cluster can be used. This can involve introducing SparkStreaming. Given that the models act on transactional data, and it isdesirable to limit the rate and size of messages that are be processedin that fashion, the ability to extract only the fields required can beuseful. For efficiency reasons, this filtering should take place on theconsumer side of LogStreaming. In that scenario, the models andalgorithms will be executed on MAS-side, leveraging short-termper-subscriber history of messages. The outcome, including any changesto TCP configuration, will have to be provided, on a per-subscriberbasis, back to the ADC.

It should be understood that this disclosure relates primarily to thefirst design described above. However, in some embodiments, regardlessthe approach chosen, MAS may communicate decisions or updated parametersback to the ADC. This may extend the Nitro-based APIs between MAS andthe ADC. Moreover, this use case may not rely on a deployment of MASthat consists of more than one telemeter cluster nodes. In other words,the systems and methods of this disclosure are compatible with thesingle-node deployment of MAS Advanced Analytics.

FIG. 13 is an example high-level architecture block diagram. Thecomponents that contribute to the feature are divided into four mainareas (denoted on FIG. 13): The components in Area 1 relate to inputdata. Thus, these components implement the functionality describedabove, in terms of generating the Input Data required for the inferencealgorithms. In some embodiments, these components can reside entirely inthe ADC packet engine. Area 2 relates to models and algorithms. Asdiscussed above, the application of the ML models and implementation ofthe inference algorithms can reside in the packet engine, but thetraining of the models, utilizing accumulated data sets, can reside inthe MAS Telemetry Cluster. Area 3 relates to analytics reports. In someembodiments, these components reside in MAS, divided between adding newmetrics in an AfDecoder output towards a PgXL database schema and addingnew reports in a MAS web-based UI. Area 4 relates to closing the loop.These components can implement passing the outcomes of training the MLmodels from MAS to the ADC, which can result in updating relevantconfiguration settings, and applying these changes, starting from newTCP connections.

At a high-level, the end-to-end data processing flow is as follows:

First, the packet engine processes TCP connections (using a layer 4 orabove vserver). During the course of each TCP connection, it identifiesperiods of active data transfer, for which it calculates the inputfields described above. More specifically, the raw metrics can beextracted. After the packet engine has received trained model parametersfrom MAS, as described below, additional composite metrics can also becalculated.

Next, at the end of each TCP connection, the packet engine generates alayer 4 transactional record that includes the input fields above and istransferred using the LogStreaming transport interface from the packetengine to MAS.

The transactional records are made available (e.g., in shared memory)and the LogReceiver and AfDecoder consumers ingest them, each to fulfila different purpose. LogReceiver can transmit the individual records toHDFS and AfDecoder can generate aggregate metrics to be stored in thePostgresXL database schema. It is worth noting that these two processingpaths can be otherwise independent: Scale out can be implementeddifferently and local vs. centralized operation can also vary.

On the LogReceiver path, once a number of transactional records havebeen written to a file in the Hadoop Distributed File System (HDFS)(e.g., upon file rotation, or per five minutes), a Preprocessor willreceive a notification (e.g., via the Redis message queue). Thepreprocessor can invoke a LogApiServer API, which can spawn a Spark jobthat will analyze the newly available transactional records. This Sparkjob can extract the subset of records and columns that providemeaningful input fields and accumulate them in a structured store, suchas Pg-XL.

Also as invoked through a LogApiServer API, another process or job canperiodically check the collection of observations that have beengathered so far, and decide whether to invoke the initial training orre-training of the ML models. This process or job can implement thepipeline of classification models. Once training is complete and iflearning metrics are acceptable, the resulting model parameters will besent to the ADC via a Nitro-API call, which will result into updatingrespective (hidden) configuration settings. These can apply tosubsequent TCP sockets. On the AfDecoder path, the inference results canbe extracted, and can be used for enriching the metrics stored in thePostgresXL database schema, with the detected network type, as well asthe congestion level and signal quality scores. These can be used tocreate new analytics reports.

In some embodiments, accuracy higher than 90% can be achieved indetecting the mobile network type using simple machine learning models(small decision trees), and a limited subset of the features such asavg. throughput, avg. bytes-in-flight (BIF), min./avg. RTT, etc.However, in the context of generating the inference results, andespecially to drive Adaptive TCP policy actions, higher accuracy isdesirable to minimize the rate of “3G” observations that aremisclassified as “4G.” Also, the accuracy of classifying sessions thatare too slow or too short as “2G” is also relatively crucial, since theproposition is that a very conservative “catch all” TCP profile can beapplied in that scenario.

Based on the above, in some embodiments, “2G” connections can first beexcluded from all the rest, ideally using a simple model such as alogistic regression model that uses only a few features, such as onesrelated to average throughput (or BIF) and/or average latency (RTT). Tosubsequently discriminate between “3G” and “4G”, and given the scale ofaccuracy improvement that is desirable, specific characteristics ofthese two technologies can be exploited. Specifically, WCDMA and LTEtechnologies use different TTI. WCDMA uses 2 ms or much higher (10 ms),depending on whether it is HSDPA/HSPA/HSPA+ or plain old UMTS, whereasLTE uses 1 ms. Thus, the distributions of (ACK) packet inter-arrivalintervals of WCDMA and LTE downloads are different, in terms of thedistinct peaks they exhibit, coinciding with multiples of the TTI ofeach.

The principles of characterizing data transfers that take place inmobile networks, in terms of the underlying network congestion andsignal quality, are described further below. As depicted in FIG. 14,packets flowing between the ADC and the mobile terminal (UE) experiencethe combined effects of network congestion (occasionally not only at theeNodeB, as depicted) and wireless loss on the air interface, which mayrelate to bad reception. Consequently, before characterizing networkcongestion and wireless loss, it can be helpful to separate them out,which can be challenging. Network congestion is exhibited as packetdelivery delay, due to network queue build-up and competition withcross-traffic. However, due to the (H)ARQ retransmission implemented by3G and, wireless losses also translate to delays. This is illustrated inFIG. 15, as well as in FIG. 7A described above.

One key insight is that delay increases gradually for the case ofcongestion, while it increases sharply for the case of wireless loss.Consequently, it can be helpful to differentiate between abrupt delays,which correlate with the (H)ARQ retransmission time interval, and othertypes of delays. However, the (H)ARQ retransmission interval isbearer-specific (i.e., it depends on the TTI, which is different betweenUMTS/HSxPA/4G). Also, (H)ARQ parameters (e.g. maximum number ofprocesses, maximum number of retries) are configurable by each operator.As a result, these thresholds can be adapted to each network, asillustrated in FIG. 16. The default delay threshold for detecting (H)ARQretransmissions is set to 8 ms for 3G and 7 ms for 4G.

Once the above is achieved, the measured delay can be divided into twoportions as illustrated in FIG. 17. In FIG. 17, the gradual delay causedby congestion is shown in green, while the abrupt delay that is causedby noise is shown in red.

This leads to the simplified CCL (Connection Congestion Level) and CSQ(Connection Signal Quality) formulas described further below. Generally,CSQ is measured as the average cumulative effect of delays caused bywireless retransmissions, and CCL is measured as the average cumulativeeffect of delays caused by network load (cross traffic andself-inflicted). Both metrics are calculated as a percentage of totalpackets delay. Since packet delay is strongly correlated to the numberof transferred bytes, CCL and CSQ are multiplied by a factorproportional of the transferred bytes. This factor, referred to as CQR(Connection Quality Ranking), represents the percentage drop of theconnection's throughput compared to the ideal throughput. The idealthroughput is achieved on a channel when there is negligible or nocongestion and noise. Finally, once an adequate number of CCL and CSQmeasurements are gathered, they can be divided into four (4) rankings.

In some embodiments, the boundaries can be selected simply to correspondto the respective CQI scale of each network type. The decision can bebased on experimental analysis, which suggests that CQR distributionroughly approximates the CQI distribution, as illustrated in FIG. 18.

CQI is an indicator carrying information on how good or bad thecommunication channel quality is. CQI is the information that UE sendsto the network, and practically it implies that current CQI has aparticular value, and that the UE requests to get the data with aspecified transport block size, which in turn can be directly convertedinto throughput. While the systems and methods of this disclosuregenerally do not measure packet delivery times directly, they areassumed to be correlated to ACK generation times. In other words, packetdelivery delays can be sensed by comparing inter-sending intervals ofpackets with inter-arrival intervals of corresponding ACKs. It shouldalso be understood that TCP is self-clocking. As a result, the ACK ratedepends on the segment rate, and vice versa. ISI's and IAI's are equalwhen TCP is in stable operation.

In some embodiments, feature selection can be initiated by analyzing astandard set of TCP-related attributes, including the following:

-   -   rtt_min, rtt_avg, rtt_max: Minimum, Average, Maximum RTT    -   bif_avg, bif_max: Average, Maximum bytes-in-flight (BIF)    -   thrput_avg: Average throughput    -   packet_cnt/retxpacket_cnt, ack_cnt: Total packets        transmitted/retransmitted, number of ACKs    -   rwnd_min, rwnd_max, rwnd_avg: Receive window summary statistics

However, the above features may not be adequate to achieve high levelsof accuracy. Thus, the following additional features can also beincluded:

-   -   isi_avg: Average packet inter-sending interval    -   iai_avg: Average packet inter-arrival interval    -   iai_1ms: Percentage of packets with inter-arrival interval 1        ms±200 μs    -   iai_2ms: Percentage of packets with inter-arrival interval 2        ms±200 μs    -   load1_iai_ avg: Average packet inter-arrival time in range [0,        HARQ_THRESHOLD_3G)    -   noise1_iai_avg: Average packet inter-arrival time in range        [HARQ_THRESHOLD_3G, inf)    -   load2_iai_avg: Average packet inter-arrival time in range [0,        HARQ_THRESHOLD_4G)    -   noise2_iai_avg: Average packet inter-arrival time in range        [HARQ_THRESHOLD_4G, inf)

In some embodiments, the list of features used for the network typedetection can be dynamic, and it is possible to include any metric.

The definition of how the info fields can be generated can be providedin the form of a package of scripts. In general, the scripts can performthe following tasks:

-   -   1. Read the packets one-by-one in ascending order of packet        number    -   2. For each downstream packet, append a tuple (seg_seq, seg_end,        ts, retx, acked_bytes) in a queue.        -   a. seg_seq: sequence number        -   b. seg_end: sequence number+packet length        -   c. ts: timestamp sent (high resolution)        -   d. retx: Boolean flag whether it is a TCP retransmission or            not        -   e. acked bytes: how many bytes have been acknowledged        -   f. Function: parseflow( )    -   3. For each upstream-packet (ACK)        -   a. Extract the ACK and if applicable the S-ACKs        -   b. Search in the queue and if there are packets with            pkt[‘seg_end’]<ack &&            pkt[‘acked_bytes’]<pkt[‘seg_end’]-pkt[‘seg_seq’] acknowledge            the packets and keep track of the total acked_bytes        -   c. If there is a packet with pkt[‘seg_end’]>=ack &&            pkt[‘acked_bytes’]<pkt[‘seg_end’]-pkt[‘seg_seq’] and            pkt[‘retx’] is false, then store the arrival time of that            ACK, the RTT and the BIF at the time the packet was sent. If            pkt[‘retx’] is true, no information need be kept, apart from            the loss reason, which by default is set to “congestion”        -   d. All ACK'ed packets in the queue are removed if the ACK            advances the window        -   e. Function: calc_attrs( )    -   4. For each ACK which has acknowledged a not retransmitted        packet, calculate:        -   a. The total acked bytes        -   b. The inter-arrival and inter-sending intervals        -   c. Total packet delay, mac/rlc delay (due to radio            retransmissions) and no-mac/rlc delay (due to congestion)        -   d. The compressed packet window (compressed_pkt_wnd_start,            compressed_pkt_wnd_knee, compressed_pkt_wnd_end)            -   compressed_pkt_wnd_start: The timestamp of the last                radio retransmitted packet            -   compressed_pkt_wnd_knee: The timestamp at which the                effect of the radio retransmission(s) starts reducing            -   compressed_pkt_wnd_end: The timestamp at which the                effect of the radio retransmission(s) ends            -   Functions: update_compressed_pkt_wnd( ) and                is_compressed_pkt( )        -   e. The mac/rlc retransmission status (True/False) and the            mac/rlc retransmission delay            -   i. Delay=pkt_n[‘seg_rtt’]−pkt_m[‘seg_rtt’], for n>m            -   ii. Function: is_mac_rlc_retx( )        -   f. Performs loss discrimination if the previous ACK(s) were            for retransmitted packet(s)            -   i. Function: packet_loss_discrimination( )            -   ii. If the packet preceding the retransmitted ones has                mac rlc delay higher than no_mac_rlc_delay the loss                reason is set to “corruption”        -   g. Function: store_packets_attrs( )    -   5. For each ACK which has acknowledged a retransmitted packet is        also kept the retransmission group number.

At this point, the downstream and upstream packets have been matched andthe RTT, BIF, ISI, IAI, MAC_RLC_DELAY, NO_MAC_RLC_DELAY, andLOSS_DISCRIMIN-TION have been calculated, taking into accountretransmissions and stretch-ACKs. Even though stretch-ACKs may be oflittle consequence, in some embodiments, only the delayed ACKs may beprocessed to avoid inaccuracies in the calculation of IAI and ISI. Insome embodiments, downstream and upstream matching does not constitute ahard requirement and thus can be omitted if performance considerationsrise.

The next step is the calculation of aggregates. In some embodiments, thecalculation of the averages can be done using the simple formula Sum(x1,x2, . . . xN)/N, though it may be desirable to use the cumulative movingaverage to improve space efficiency.

As described above, input data (existing and new) can be transferredfrom the ADC to MAS using the LogStreaming transport. In someembodiments, carrying the new fields in end-of-transaction records canbe sufficient. On the MAS side, ingestion will be done normally byLogStreaming transport and the LogReceiver consumer, which writes outputto RDFS.

A batch data processing path of the Telemetry Cluster can be used togenerate data sets that will be used for training the machine learningmodels and algorithms. As described above, info fields extracted fromthe transactional records (e.g., “observations”) can be accumulated inPg-XL, until an adequate number is gathered. In some embodiments, around10,000 observations can be sufficient.

Once the above condition is met, one or more Spark jobs can be initiatedvia the job scheduler (i.e. not triggered by a Telemetry API call) to(re-)train the models and/or algorithms. The outcome of this will be themodel coefficients, as well as training evaluation results.

The machine learning pipeline mentioned above can include the followingphases:

-   -   1) Network type detection (multi-class classification)        -   a) Classify 2G transactions (binary classification)    -   Model: Combination of unsupervised model (clustering) with a        supervised model (logistic regression)        -   b) Classify 3G vs 4G transactions (binary classification)    -   Model: Combination of unsupervised model (clustering) with a        supervised model (logistic regression)    -   2) Congestion level and signal quality ranking        -   a) Calculate CCL and CSQ scores    -   Only for the subset of 3G and 4G observations.    -   Formula parameters differ between 3G and 4G        -   b) Specify the ranking boundaries    -   Boundaries determined based on the 4 quartiles

In some embodiments, the combination of features having the strongestresults in terms of discriminating between different network types (2G,3G, 4G), can be the average throughput (thrput_avg) and the averageinter-arrival interval (iai_avg). Due to the Poisson-like distributionof iai_avg, the resulting classification model can be non-linear, butalso can be translated to a linear model by calculating the logarithm ofthe features, as shown in FIG. 19A. In some embodiments, addingadditional observations to the data set can increase their variability,and can decrease classification accuracy. However, using the iai_1ms andiai_2ms features described above, an improved separation between thenetwork classes can be achieved, as shown in FIG. 19B. Based on thedistribution shown in FIG. 19B, the discrimination between 3G and 4Gnetwork types is about 99.5%.

The confusion matrix for the techniques described above can berepresented as follows:

net net_cls 3G 4G 3G 3,795 20 4G 14 2,463

However, this can be approached as a non-supervised model, because thenetwork type labels may be initially unknown when first deployed. Thehigh-level steps of changing this to a non-supervised model are asfollows:

1. Apply clustering algorithm, using attributes mentioned above (e.g.thrput_avg, iai_1ms, iai_2ms, load_iai_avg, noise_iai_avg, rtt_min,rtt_max, rtt_avg, iai_avg, isi_avg). Based on our comparison betweenk-Means and Spectral clustering, the latter produces better validationresults for the case of 3G versus 4G, while the former is applied forthe case of 2G versus Non2G case.

2. The outcome of step 1 produces clusters equal to the number ofnetwork types to be classified (maximum three). Labels can be assigneddepending on the average thrput_avg across the observations of thecluster (always under the assumption that “4G” is faster than “3G”).

3. The dataset can then be split into training and testing sets, forexample using a 70%-30% ratio. Then Logistic Regression can be appliedto the training dataset, employing 10-fold cross-validation. The set ofattributes used can be the same as in step 1 above.

The resulting linear classifiers use #attributes coefficients plus theintercept, which can be stored on MAS and provided back to the ADC forapplying the network type detection model. Apart from the coefficients,the cut off threshold can also be provided to the ADC.

FIGS. 20A and 20B show experimental results for the model describedabove.

Estimating relative congestion and noise delays can be achieved throughthe following calculations:

-   -   load_delay_pct=avg(load_delay)/avg(delay)    -   noise_delay_pct=avg(harq_delay)/avg(delay)

FIG. 21 shows a plot estimating the maximum theoretical throughput of aconnection for one example computing environment. The reference line(black curve in the plot of FIG. 21) is approximated by a boundedlogarithmic function, which has the following form:

-   -   est_thrput=min(a*loglp(b*(transferred_bytes+c))+d, e)

Estimating the CCL and CSQ:

-   -   CQR=(max(est_thrput, thrput)−thrput)/est_thrput    -   CCL=CQR*load_delay_pct    -   CSQ=CQR*noise_delay_pct

The parameters of the logarithmic function can be calculated as follows:

def get_ref_connections(conn_df):  a = 1 #a in (0, 1]  thrput_avg_prev =.0  ref_conn_df = [ ]  base_net_rtt = conn_df.rtt_min.quantile(q = .1) max_net_thrput_avg = conn_df.thrput_avg.max( )  for conn inconn_df.iterrows( ):   if conn.thrput_avg >= a * conn.thrput_avg_prev:   thrput_avg_prev = conn.thrput_avg    conn.ideal_thrput_avg =min(conn.bif_avg * 8 / (1000000 * (base_net_rtt + 0.005)),max_net_thrput_avg)    ref_conn_df.append(conn)  return ref_conn_df deflog_func(x, a, b, c, d, e):  return min(a * log1p(b * (x + c)) + d, e) x= log1p(ref_conn_df.conn_len) y = log1p(ref_conn_df.ideal_thrput_avg)popt, = curve_fit(log_func, x, y)

In some embodiments, the CCL and CSQ classes conform to the CQIefficiency index of the respective network type. The following tableshows the scale of CQI efficiency index for LTE. There is a similartable for WCDMA with the difference that there are 30 classes.

CQI index modulation code rate × 1024 efficiency 0 out of range 1 QPSK78 0.1523 2 QPSK 120 0.2344 3 QPSK 193 0.3770 4 QPSK 308 0.6016 5 QPSK449 0.8770 6 QPSK 602 1.1758 7 16QAM 378 1.4766 8 16QAM 490 1.9141 916QAM 616 2.4063 10 64QAM 466 2.7305 11 64QAM 567 3.3223 12 64QAM 6663.9023 13 64QAM 772 4.5234 14 64QAM 873 5.1152 15 64QAM 948 5.5547

For facilitating the mapping between CQI efficiency index and CQR, theformer can be rescaled in the [0, 1] range having 0 to correspond to thebest quality and 1 to the worst. The resulted classes will have anarc-shaped form, as depicted in FIG. 22. The proposed connection qualityranking implies that connections with negligible (H)ARQ retransmissionscan be classified as having ‘Good’, or ‘Fair’ signal conditions becauseof the interference caused when the cell is congested. In such cases,the bad signal conditions are witnessed by low throughputs due todecreased MCS.

FIGS. 23A and 23B show the results of implementing the above CCL/CSQalgorithms on the datasets at hand, separately for observationsclassified as 3G and 4G, respectively.

In some embodiments, in addition to the reports that can be madeavailable to the end-user, the systems and methods of this disclosurecan also generate internal reports to validate that the inferencealgorithms produce reasonable results.

Parameters of the ML models and inference algorithms can include any ofthe following:

-   -   Linear classifier (logistic regression) coefficients    -   HARQ threshold: Empirically set to ˜8 ms for 3G and ˜7 ms for 4G    -   Per network type base RTT: net_rtt parameter    -   The ranking boundaries of CCL and CSQ per network type

These parameters can be passed from MAS back to the ADC each time thereis a need to update them, for example following the initialbootstrapping or potential retraining of the ML models. For reasons ofrobustness, the parameters can be verified, by comparing againstthresholds, before the outcome of training is communicated to the ADCfor applying the models. In some embodiments, this MAS-ADC integrationwill leverage Nitro API, extending existing interfaces, or leveragingstylebooks. To facilitate applying changes by hand, for example as partof advanced configuration, testing, or troubleshooting, the sameparameters can be made available as hidden CLI arguments.

As described above, some input fields, including the detected networktype and CCL/CSQ classes, can be included in LogStreaming recordstransferred from the ADC to MAS over LogStreaming transport.Consistently with the other MAS analytics reports, the afdecoderextension of LogStreaming can be extended to ingest those fields andimplement summarization/aggregation, before storing in a relationaldatabase of MAS. In some embodiments, this can facilitate the embodimentof the analytics reports described above.

Various elements, which are described herein in the context of one ormore embodiments, may be provided separately or in any suitablesubcombination. For example, the processes described herein may beimplemented in hardware, software, or a combination thereof. Further,the processes described herein are not limited to the specificembodiments described. For example, the processes described herein arenot limited to the specific processing order described herein and,rather, process blocks may be re-ordered, combined, removed, orperformed in parallel or in serial, as necessary, to achieve the resultsset forth herein.

It will be further understood that various changes in the details,materials, and arrangements of the parts that have been described andillustrated herein may be made by those skilled in the art withoutdeparting from the scope of the following claims.

We claim:
 1. A method comprising: using, by a device, a percentage ofinter-arrival intervals of network packets within one or more firstthresholds or a probability of a network packet having an inter-arrivalinterval within one or more second thresholds to distinguish between aplurality of types of networks; determining, by the device,inter-arrival intervals of one or more packets of a transport layerconnection; and identifying, by the device, a type of network for thetransport layer connection based on at least the inter-arrival intervalsof one or more packets.
 2. The method of claim 1, wherein the pluralityof types of networks comprises one of a mobile network or a fixednetwork.
 3. The method of claim 1, wherein the plurality of types ofnetworks comprise one of a 2G, 3G, 4G or 5G network.
 4. The method ofclaim 1, further comprising using, by the device, a classification modelto distinguish between different types of networks based at least onusing the inter-arrival intervals of one or more network packets asinputs to the classification model.
 5. The method of claim 1, furthercomprising receiving the one or more packets of the transport layerconnection and determining the inter-arrival intervals from receipt ofthe one or more packets.
 6. The method of claim 1, further comprisingreceiving, by the device, the one or more packets of the transport layerconnection, and wherein determining the inter-arrival intervals of theone or more packets comprises determining the inter-arrival intervalsfrom the received one or more packets.
 7. The method of claim 1, furthercomprising: selecting, by the device, a transport control protocol(“TCP”) profile from a set of predetermined TCP profiles for configuringthe transport layer connection; modifying, by the device, the selectedTCP profile based on the identified type of network for the transportlayer connection; and applying, by the device, the modified TCP profileto the transport layer connection to optimize network performance forthe transport layer connection.
 8. A system comprising: one or moreprocessors, coupled to memory and configured to: use a percentage ofinter-arrival intervals of network packets within one or more firstthresholds or a probability of a network packet having an inter-arrivalinterval within the one or more second thresholds to distinguish betweena plurality of types of networks; determine inter-arrival intervals ofone or more packets of a transport layer connection; and identify a typeof network for the transport layer connection based on at least theinter-arrival intervals of one or more packets.
 9. The system of claim8, wherein the plurality of types of networks comprise one of a 2G, 3G,4G or 5G network.
 10. The system of claim 8, wherein the one or moreprocessors are further configured to establish a classification model todistinguish between different types of networks based on using at leastthe inter-arrival intervals of one or more network packets as inputs tothe classification model.
 11. The system of claim 8, wherein the one ormore processors are configured to receive the one or more packets of thetransport layer connection and determine the inter-arrival intervalsfrom receipt of the one or more packets.
 12. The system of claim 8,wherein the plurality of types of networks comprises one of a mobilenetwork or a fixed network.
 13. The system of claim 8, wherein the oneor more processors are further configured to receive the one or morepackets of the transport layer connection, and wherein determining theinter-arrival intervals of the one or more packets comprises determiningthe inter-arrival intervals from the received one or more packets.
 14. Asystem comprising: one or more processors, coupled to memory andconfigured to: use an average of round trip times of network packetswithin one or more thresholds to distinguish between a plurality oftypes of networks; determine round trip times of one or more packets ofa transport layer connection; and identify a type of network for thetransport layer connection based on at least the round trip times of oneor more packets.
 15. The system of claim 14, wherein the one or moreprocessors are further configured to use one of a maximum round trip ora minimum round trip time to distinguish between the plurality of typesof networks.
 16. The system of claim 14, wherein the plurality of typesof networks comprises one of a mobile network or a fixed network. 17.The system of claim 14, wherein the plurality of types of networkscomprises one of a 2G, 3G, 4G or 5G network.
 18. The system of claim 14,wherein the one or more processors are further configured to establish aclassification model to distinguish between different types of networksbased on using at least the round trip times of one or more networkpackets as inputs to the classification model.
 19. The system of claim14, wherein the one or more processors are further configured to receivethe one or more packets of the transport layer connection, and whereindetermining the round trip times of the one or more packets comprisesdetermining the round trip times from the received one or more packets.20. The system of claim 14, wherein the one or more processors arefurther configured to: select a TCP profile from a set of predeterminedTCP profiles for configuring the transport layer connection; modify theselected TCP profile based on the identified type of network for thetransport layer connection; and apply the modified TCP profile to thetransport layer connection to optimize network performance for thetransport layer connection.